lcc-win32

[Keith Thompson]

The same, but with an open mind, rather than anally clutching to the
strict wording which, quite often, fails to reflect the actual intent of
the authors.

Perhaps you can provide some evidence that the actual intent of the
authors is consistent with your interpretation. I don't believe it
is.

[...]

If expecting <time.h> to provide the specification of a package, rather
than the descriptions of a bunch of *unrelated* functions is wishful
thinking, then you're right, of course.

I don't particularly expect <time.h> to provide the specification of a
"package". I don't know why you do. I understand that you wish it
did; so do I (see "wishful thinking", above) (I'm not 100% sure what
you mean by the word "package" anyway.)

Nor do I expect <stdlib.h> to provide the specification of a "package".

[...]

The only *sensible* requirement about the size of the asctime output is
that it accomodates the largest year supported by the <time.h>
implementation, usually the largest year representable by time_t.

What a pity that the standard doesn't actually say that. In fact what
the standard actually *does* say directly contradicts your
interpretation.

And I know this won't do any good, but take your personal abuse
("reading impaired" et al) and shove it.

 

[Dan Pop]

Perhaps you can provide some evidence that the actual intent of the
authors is consistent with your interpretation. I don't believe it
is.

What do you believe the actual intent was? To provide a deliberately
broken specification for asctime()?

IMHO, they were looking for a simple way of specifying the actual format
of asctime's output and they made a less than optimal choice. They
didn't meant asctime to be seen as a standalone member of the package.

I don't particularly expect <time.h> to provide the specification of a
"package". I don't know why you do.

Why don't we have a single header covering the whole of the standard C
library, something like <stdc.h> ? Because the standard C library was
logically divided into packages and each package assigned its own header.

I understand that you wish it
did; so do I (see "wishful thinking", above)

I would have been perfectly happy with <stdc.h>, no wishful thinking.
I was merely commenting on what the committee actually did. If you
disagree, ask in comp.std.c.

(I'm not 100% sure what you mean by the word "package" anyway.)

Then get yourself an English dictionary and peruse it. If still in doubt,
post the most likely candidate definitions and I'll tell you which it is.

Nor do I expect <stdlib.h> to provide the specification of a "package".

Neither do I, for reasons *already* explained in my previous post.
Reading impaired?

[...]

The only *sensible* requirement about the size of the asctime output is
that it accomodates the largest year supported by the <time.h>
implementation, usually the largest year representable by time_t.

What a pity that the standard doesn't actually say that. In fact what
the standard actually *does* say directly contradicts your
interpretation.

Indeed, if you anally clutch at the actually wording, without even
trying to see the intent. Anyway, I never filled a struct tm by hand
and then passed it to asctime and I don't plan to do that in the future,
so the actual definition happens to be good enough *for me*, even if it's
broken in the general context of the <time.h>.

Dan

 

[Keith Thompson]

Dan, I'm not going to waste any more time on this.
I'm right, you're wrong, and I'm done here.