Why C is really a bad programming language

[Default User]

| (i.e. '>') so we can figure out who said what?

What standards document specifieds '>'?

XanaNews recognizes '|' for purposes of color-coding reply levels. I'd
prefer you used '>' the way most others do, but I'm not hard over about
it.



Brian

 

[jameskuyper]

| (e-mail address removed) wrote:
|> | (e-mail address removed) wrote:
|> |>> C does not mandate the use of 32-bit integers for time_t.
|> |>> This is truly an implementation issue, and the fix is so easy that
|> |>> implementors have no excuse for not fixing the problem right now.
|> |>
|> |> Binary compatibility with existing code seems like a pretty good excuse
|> |> to me. ....
This is a "mixing ABIs" issue. You can describe this scenario for any 32
bit to 64 bit transition, including full pure 64-bit programs that try to
link to 32 bit modules. This is to be avoided.

And the need to avoid that is, as originally stated, "a pretty good
excuse" for "not fixing the problem right now". It must be dealt with
eventually, and there are some advantages to doing it as soon as
possible, but this is one of the disadvantages of doing it as soon as
possible.

 

[jameskuyper]

| I identified the source of the non-standard quoting characters with
| sufficient precision for the context. (e-mail address removed) was the
| most recently cited Phil, and the one I was actually referring to. ....
What standard?

I don't know, or care, whether it's a de-jure standard, or only de-
facto, but one way or another it is a standard, and the consequences
are the same either way: newsreaders excepting that quoting mechanism
are going to mess up messages that don't adhere to it.

 

[Nobody]

| I suspect that the Unix folk are relying upon most 32-bit platforms
| becoming obsolete before 2038.

Don't assume too much. There are still 16-bit platforms around in very small
embedded controllers.

None of which run Unix, AFAICT.

[And in my view, a "very small" embedded controller means an 8-bit
architecture.]

I doubt your coffee maker needs to go beyond a 32-bit
platform even in 2040. But it will need to calculate time correctly, so a
mixed 32/64 bit ABI where time_t is 64 bits would be doable.

The average domestic appliance will work perfectly well using the year the
product was designed as the epoch. There's no reason to use 1970 unless
you specifically require POSIX compliance. Actually, there's not much
reason to use time() either.

 

[Nobody]

|> FYI, the whole mess with 64 bit file offsets was done all wrong. It should
|> have simply been a new ABI that has a slightly different library name.
|> Keep both libraries where legacy binaries exist. All recompiles would by
|> default use the new ABI definitions.
|
| There are other problems with file offsets, e.g. fseek/ftell using "long"
| for the offset rather than off_t, passing file descriptors between
| processes, etc.

When are those going to be fixed?

That depends upon how you define "fixed".

The problem with fseek/ftell is in the C standards; there isn't anything
an OS developer can do about that without using a 64-bit "long".

 

[Phil Carmody]

None of which run Unix, AFAICT.

But do the architectures preclude the running of a Unix by a sufficiently
keen hobbyist?

[And in my view, a "very small" embedded controller means an 8-bit
architecture.]
Agreed.

I doubt your coffee maker needs to go beyond a 32-bit
platform even in 2040. But it will need to calculate time correctly, so a
mixed 32/64 bit ABI where time_t is 64 bits would be doable.

The average domestic appliance will work perfectly well using the year the
product was designed as the epoch.

The average domestic appliance will work perfectly well using the time
of power-on as the epoch.

There's no reason to use 1970 unless
you specifically require POSIX compliance. Actually, there's not much
reason to use time() either.

Absolutely.

Phil

 

[Kaz Kylheku]

Don't assume too much. There are still 16-bit platforms around in very small
embedded controllers. I doubt your coffee maker needs to go beyond a 32-bit
platform even in 2040. But it will need to calculate time correctly, so a
mixed 32/64 bit ABI where time_t is 64 bits would be doable.

LOL!

A coffee maker which knows 24 hour time, and what day of week it is, so
that brewing can be scheduled by day of week, is ridiculously over-featured.

That kind of time support is more suitable for a telephone answering machine.

 

[Old Wolf]

Old Wolf wrote:
 > At least the C++ developers had the option of coding to
 > a standard, so that they could upgrade in future without
 > breaking.

There have been a few incompatible C++ standards around.

There is only one official one (the ISO one). I guess
you are talking about de-facto standards. I would
think it obvious that the ISO standard is the better
one to code to.

I have no idea what Nick Keighley is talking about,
perhaps his developers thought they were coding
to a standard but actually had mistakes.

 

[James Kuyper]

There is only one official one (the ISO one).

I count two ISO standards: 1998 and 2003. Which one are you referring
to? They are, as he said, somewhat incompatible with each other.

 

[Dik T. Winter]

>
> There is only one official one (the ISO one). I guess
> you are talking about de-facto standards. I would
> think it obvious that the ISO standard is the better
> one to code to.

Now perhaps. But look at wat you wrote: "At least the C++ developers *had*
the option of coding to a standard, so that they *could* upgrade in future
without breaking". Which is wrong. Once upon a time we obtained a
program written in C++ that had to be implemented on SGI using Irix and
on Sun using Solaris. It was impossible to create from the C++ source we
received a single source that would compile on both platforms, while the
C++ compilers on them both adhered to some standard.

 

[Richard Bos]

| I suspect that the Unix folk are relying upon most 32-bit platforms
| becoming obsolete before 2038.

Don't assume too much. There are still 16-bit platforms around in very small
embedded controllers. I doubt your coffee maker needs to go beyond a 32-bit
platform even in 2040. But it will need to calculate time correctly, so a
mixed 32/64 bit ABI where time_t is 64 bits would be doable.

Coffee makers need the time? Time differences, yes, but that on a very
small scale. clock() would more than suffice on any halfway decent
system, and time_t rolling over will result in, at most, an over-brewed
pot of what is after all vile muck at the best of times.

Richard

 

[Richard Bos]

(e-mail address removed) writes:

Note that off_t is not defined in standard C; it's defined by POSIX.

That's irrelevant in this case; the errors made by POSIX in its
/changement/ can still be applied to the coming change-over of time_t.

Richard

 

[Stephen Sprunk]

LOL!

A coffee maker which knows 24 hour time, and what day of week it is, so
that brewing can be scheduled by day of week, is ridiculously over-featured.

I'm not sure that's over-featured. It needs at least a functioning
24-hour clock plus day-of-week so that it can brew coffee (or not) at
the proper time each morning. Knowing the year and date seems like
overkill, but it could allow the machine to adjust for daylight savings
time.

I'm not a coffee person, but the thermostat for my house has a full
clock built in for exactly these reasons: the temperature can be set by
hour and by day of week, which is very useful, and it automatically
adjusts itself for DST. My automatic pet feeder doesn't bother with
DST, though, so all it needs is the 24-hour clock plus day-of-week since
they think I need the ability to feed my cats at different times on the
weekend; _that_ is probably overkill.

That kind of time support is more suitable for a telephone answering machine.

Those still exist? I thought everyone had voice mail by now, and I'd
certainly expect any current model to be out of service by 2038.

For any embedded device, a lifespan of 68+ years seems ridiculous, so an
epoch that started the year of manufacture should be sufficient to avoid
Y2038 problems. Many embedded OSes run a subset of POSIX, though, so
I'm not sure it's possible to change the epoch. Even if that's a
violation, though, presumably that would be documented and the
manufacturer would check their own code to make sure it didn't depend on
a particular epoch.

The real problem seems limited to general-purpose computers that need to
run arbitrary software, which means a fixed epoch.


S

 

[Keith Thompson]

Coffee makers need the time? Time differences, yes, but that on a very
small scale. clock() would more than suffice on any halfway decent
system, and time_t rolling over will result in, at most, an over-brewed
pot of what is after all vile muck at the best of times.

My coffee maker has a clock, and is capable of automatically brewing
coffe in the morning so it's ready when I get up. To do this, it has
to know what time it is.

Certainly it could (and likely does) use something other than time_t
to represent the current time. But it *could* use time_t, and in that
case it would benefit from a time_t that doesn't run out of bits in
2038.

 

[Default User]

Coffee makers need the time? Time differences, yes, but that on a very
small scale. clock() would more than suffice on any halfway decent
system, and time_t rolling over will result in, at most, an
over-brewed pot of what is after all vile muck at the best of times.

Almost all coffee makers I've seen have a clock. Many feature a delayed
start. You set it to start coffee at a time prior to wake-up.





Brian

 

[Richard Bos]

No. MS-Windows has a time facility. C implementations running on Windows
have time_t's, but those don't have to be related to the underlying time
structures of the OS they run on.

Windows also uses 1970-1-1 as its epoch (although if you're writing
portable code, you won't be making any assumptions about the epoch).

I thought it used 1980, but it turns out that's just for the FAT
filesystem.

MS-DOS used 1980. The FAT, amusingly enough, didn't use 1980-01-01, but
(at least, that's what a little experiment seemed to indicate)
1980-00-00.

However, time_t has been 64-bit since Visual C++ 2005.

In VC++. That does not mean that other implementations on Windows have
to use the same kind of time_t.

Richard

 

[Richard Bos]

But do the architectures preclude the running of a Unix by a sufficiently
keen hobbyist?

Feh. That's his problem. If the hobbyist is keen enough to run Unix on a
coffee maker, he can damn well be keen enough to make sure his time_t's,
rolling over or not, don't bother others.

Richard

 

[Richard Bos]

Almost all coffee makers I've seen have a clock. Many feature a delayed
start. You set it to start coffee at a time prior to wake-up.

Hm, you have more advanced coffee makers than my family ever had.

Mind you, I don't drink the muck myself, so that's not a great shock.

Richard

 

[Default User]

Hm, you have more advanced coffee makers than my family ever had.

Mind you, I don't drink the muck myself, so that's not a great shock.

I'm with you as far as drinking it. I have a fancy one that I selected
as my 20-year anniversary gift from the cumpnee. I have it for making
coffee for guests.




Brian

 

[Nobody]

But do the architectures preclude the running of a Unix by a
sufficiently keen hobbyist?

That depends upon your definition of "Unix". If you want "real" Unix
memory management, permission enforcement, etc, any 16-bit architecture is
going to require a lot of additional hardware which is built-in to most
32-bit CPUs.

Even on a 68000 (which in most respects is a 32-bit architecture), getting
something close to Unix working takes some effort, and it isn't going to
run most "Unix" software without modification.

For a 16-bit architecture, this sort of task would need someone who is way
beyond "keen" and quite firmly in the obsessive-compulsive category.