RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye <bradds@ix.netcom.com>]

On Thursday, April 11, 1996, Robert Dewar wrote...
> Chuck said
> 
> "There are a lot of things that are intentionally not spelled
> out by standards.  Sometimes this is because the standard
> writers want to limit the scope of the document to keep it
> legible and usable, and sometimes it's because they don't want
> to preclude implementors from offering usable products
> based on current technology or from adding capabilities and
> value to future products."
> 
> This is a sorry excuse for an obvious oversight if you ask me. All that
> is needed for read is one of the following two sentences:
> 
> The buffer must be long enough to accomodate the data actually read
> 
> or
> 
> 
> The buffer must be at least the length corresponding to the value of
> the count parameter.
> 
> I don't really care which is chosen, I prefer the second but could 
> certainly live with the first, but I do NOT find it acceptable to
> leave this unstated. This kind of carelessness in specification
> which seems endemic in the C runtime library, is bound to lead
> to misunderstandings and portability problems. No one is asking
> for over-specification, or for exhaustive and exhausting formality,
> just for a clear informal statement of what is intended!
> 

Try to keep in mind the spirit of defensive programming:
If there's something ambiguous about the way you could implement
something, and one implementation is safe regardless of how you interpret
the ambiguity, the other implementation only works under one specific
interpretation, then defensive programming (and portable programming) will
encourage the code that works under all circumstances. Consider:

for (size_t i = 0; i < 10; i++) do_stuff();

versus

for (size_t i = 0; i != 10; i++) do_stuff();

Even though you *know* that i will never be greater than 10, even though
"not equals" should always stop the loop after the tenth iteration,
practically every programmer will write the first loop in preference to
the second. This has nothing to do with standards; the standards say that
i is a local, stack-based variable, not global, and since it is not
volatile or referenced by anything else, do_stuff() couldn't modify it,
even another thread couldn't modify it. But should your memory chips fail,
or do_stuff() accidentally trash the stack with a pointer, then the first
loop will never let i get out of the range of 0 <= i < 10, while the
second loop might.

Similarly, defensive/portable/paranoid code (which is what most of us
strive to write) will try to ensure that your buffer is big enough to
support the byte-count given to read. This is no cop-out; this is being
cautious. And there's even a good reason for it: the C run-time is allowed
to pad the end of a file with zero bytes. Just because you *know* that
file is only 68 bytes, you can't rely on getting back only 68 bytes. C can
pad that with zeroes to some system-defined line or page size (this is in
the standard mostly to support mainframe computer text modes). So you
could get back 80 or 132 bytes (the line size of most text files on a
mainframe), 512 or 1024 bytes (the sector size of most files on a PC or
workstation), or 4096 bytes (the memory page size under Win32), or any
value in between, including 68 bytes (what's actually in the file).

Now, whether a file is padded with zeroes is implementation-defined, which
means that your compiler manuals need to specify whether this happens. But
it's *intentionally* left out of the standards, not as a cop-out or
silliness, but because of real-world concerns. And it's just one more good
reason to consult your local manuals for C or POSIX and *not* the
standards documents. Standards documents are for vendors, not for
programmers.