From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: Bradd W. Szonye Subject: RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/20 Message-ID: <01bb2ed2.425fb900$65c2b7c7@Zany.localhost>#1/1 X-Deja-AN: 150607763 references: <4kk9e1$he1@nntp.Stanford.EDU> organization: Netcom x-netcom-date: Sat Apr 20 10:55:36 AM CDT 1996 newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-20T10:55:36-05:00 List-Id: 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.