ANSI C.

[Doug Gwyn <gwyn>]

> I understand why they originally took pointers; but the need
> is no longer there.  Now is the time to correct old mistakes
> not propagate them.  A number of other functions are defined
> by the standard that differ from the same functions on UNIX
> (at least some versions of UNIX) and people are going to have
> to make a number of changes to their code anyway.  It wouldn't
> be that difficult for the standard to define these functions
> with completely different names.

I suspect it was much easier to get the committee members to
all agree on an acceptable definition that covered the functions
already in use than it would be to get them to agree upon totally
new interfaces to the time functions.  Pointer parameters are not
necessarily a "mistake", although they are not the best way to
design these functions if one were to do so TODAY.  The job of
porting applications forward to the new X3J11 environment is much
easier if it is compatible with the current (poorly defined) one.

The fact of the matter is, most good commercial implementations of
non-UNIX C provided UNIX-compatible library routines all along.
The most notable exception was Whitesmiths, Ltd., and even then
one could get a UNIX-compatible library from Plum Hall, Inc.  The
X3J11 standard is just defining what an application shall be able
to count on in all conforming environments; those of us who have
been hauling around our own C libraries will be glad to have them
provided for us uniformly across all systems.

> There really should be a note here that the meanings of the
> values of time_t are implementation defined.

Some clarification might indeed be helpful.  The meaning of time_t
data lies in how they are used, which the library function
definitions explain.

> One of the biggest problems with the K&R C manual is the things
> that it doesn't explicitly mention.  It often takes a student
> of theological research to find the various hints and put them
> together to make a definite rule.  Please don't make this new
> standard work the same way.  i.e. don't leave the readers with
> the idea that "if we didn't mention something, then you can do
> what you want with it".  If something is implementation dependent
> then the standard should explictly say so.  If something isn't
> defined in the standard then we should assume that this was an
> omission to be corrected in the future, not a deliberate loophole
> that every implementor is free to interpret as he wishes.

X3J11 has nicely addressed most of the ambiguities and omissions
in K&R.  I think it is implicit in any such standard that whatever
has not been defined in the standard has no guarantees of any kind.
There are uncountably more things not explicitly addressed by the
standard than are addressed; it would be infeasible to anticipate
them all.  If you can identify some specific items that need to be
addressed you should bring them to the attention of the X3J11
committee ASAP.

I believe the intent is to specify no more and no less than the
rules that MUST be followed by a conforming implementation.  This
implies that anything not specified must NOT be relied on by
portable applications code.  One need not guess.

> This is supposed to be a scientific
> document giving precise rules; it isn't supposed to be the bible
> for some religion of C-worshippers who will spend hours pondering
> its mysteries and trying to interpret its hidden meanings.

Agreed, except that "scientific document" is putting it too strongly.
The standard represents a consensus of experts, and as such has
compromises (like not insisting on the ASCII character set) and
weaknesses (like not providing for variable dimensions on formal
array parameters).  What one hopes is that it will be "good enough"
to promote a uniform C environment.  My feeling is that it will be.

Actually, K&R wasn't too bad, but one had to THINK and UNDERSTAND
the ideas and "spirit" of the C language, and a lot of people
obviously had trouble in these areas.  X3J11 is much more explicit.

> Just look at the articles that continually appear in this news group.
> Far too many of them are discussions about what K&R really meant
> when they said such-and-such, and proofs using quotations from
> three different sections of the book to show what they really had
> in mind.  Probably at least half of the articles in any year are
> more or less identical with half the articles in any other year.
> Wouldn't it be nice to have a document which explicitly tells us
> how things are supposed to be instead of one which encourages such
> time-wasting discussions?

Exactly.  BUT don't expect that to stop idiotic postings to the
news group.  Many of them in the past could have been resolved
by reading VERY CLEAR statements in K&R, but the posters didn't
bother to look them up.

I think part of the problem is that people are getting incorrect
explanations from sources such as amateur hacker journals (and
even this newsgroup!), and they don't realize that people
propagating bogus information don't know what they're talking
about.  There is a lot of "unlearning" to be done if one has
acquired C "knowledge" from such sources.