asctime.c
Paul Eggert
eggert at CS.UCLA.EDU
Thu Aug 5 19:49:47 UTC 2004
"Clive D.W. Feather" <clive at demon.net> writes:
> if sizeof (long) is 32, you don't have to support it because the entire
> line would be too long, right?
Sorry, I don't know. My guess is that if someone ever builds a
machine with sizeof(long)==32, then POSIX will have to get fixed.
> With that assumption, both C89 and C99 have the "sizeof ordering" you
> desire. Without it, I think that code is broken anyway.
Well, I admitted it was a less-clean example. Though your conclusion
isn't quite right: the sizeof-using code works correctly on C89 hosts
where "int" and wider types contain holes, but types narrower than
"int" do not contain holes. Quite possibly some of the weird hosts
you're talking about fall into this category. C99 relaxed sizeof
rules breaks the code on any such hosts.
If these two examples don't satisfy you, here's another one, again
taken from GNU coreutils:
int
open_safer (char const *file, int oflag, ...)
{
int fd;
mode_t mode = 0;
if (oflag & O_CREAT)
{
va_list args;
va_start (args, oflag);
if (sizeof (int) <= sizeof (mode_t))
mode = va_arg (args, mode_t);
else
mode = va_arg (args, int);
va_end (args);
}
fd = open (file, oflag, mode);
...
}
Now that I think of it, this very subject came up recently in the
austin-group-l mailing list, e.g.,
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=6542>.
It was kind of a mess, if I recall.
> I hope you say this "only for code being maintained, not for new code".
> That way it will eventually die out.
The old code won't die out for the forseeable future, I'm afraid.
And I don't see the point of warning programmers even for new code.
Why waste programmers' time with worries about porting to theoretical
hosts that don't exist now and aren't ever likely to exist?
They have more important things to worry about.
More information about the tz
mailing list