* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) @ 1996-04-12 0:00 Chuck Karish 1996-04-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) Dave Emery roped me into this discussion, and now that I see how nastily some people choose to express their frustration with a ill-defined problem, I'm not sure whether to thank him. Anyway, the problem as he posed it to me is whether code like /* sample 1 */ char buf[100]; ... i = read (fd, buf, 200); is legal under the C and/or POSIX.1 standards. My understanding is that it conforms to the C and the POSIX.1 standards but that it is not guaranteed to work. Neither ISO/IEC 9945-1 (POSIX.1) nor ISO/IEC 9989 (Standard C) specifies the details of storage in the calling environment. This means that a conforming implementation could, but need not, automatically adjust storage to allow 200 bytes of data to be stored though only 100 bytes were allocated. POSIX.1 specifically allows the implementation to report an error for a condition that is not spelled out in the Standard: Implementations may support additional errors not included in this clause, may generate errors included in this clause under circumstances other than those described in this clause, or may contain extensions or limitations that prevent some errors from occurring. My understanding is that this thread started around a discussion of bounds checking under Linux that seems to go beyond the requirements of POSIX.1. According to the wording quoted above, such extra stringency is allowed by POSIX.1. 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. Anyone who craves a standard that describes every possible aspect of system behavior with complete logical precision is invited to study the later writings of Rene Descartes and then get back to us. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Chuck Karish @ 1996-04-11 0:00 ` Robert Dewar 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert Dewar @ 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root 1996-04-21 0:00 ` Mike Rubenstein 0 siblings, 2 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Bradd W. Szonye @ 1996-04-21 0:00 ` Danette & Murray Root 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Mike Rubenstein 1 sibling, 1 reply; 177+ messages in thread From: Danette & Murray Root @ 1996-04-21 0:00 UTC (permalink / raw) on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com> wrote: =>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(); while the gist of your diatribe made sense, this was silly. Any 'programmer/software engineer/title of your choice' who can't tell the difference between 'not equal' and 'is less than' is a moron, and deserves his fate. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-21 0:00 ` Danette & Murray Root @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Sunday, April 21, 1996, Danette & Murray Root wrote... > on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com> wrote: > > > =>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(); > > while the gist of your diatribe made sense, this was silly. > Any 'programmer/software engineer/title of your choice' who can't tell the > difference between 'not equal' and 'is less than' is a moron, and deserves > his fate. Both code fragments I gave are legal and they work. In fact, they're both safe. The programmer who uses the second one is merely not being "defensive" and in fact the STL requires the second syntax for a lot of iterators. My point is that programmers who provide counts bigger than their buffers are relying on nitpicky aspects of the standard, just as programmers who test loops with "not equal" are relying on "nitpicky" aspects of that operator. In the loop case, programmers always use "defensive" code that will never break, while in the buffer case, too many programmers use "defenseless" code that may break if the data size changes. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root @ 1996-04-21 0:00 ` Mike Rubenstein 1996-04-22 0:00 ` Tom Payne 1 sibling, 1 reply; 177+ messages in thread From: Mike Rubenstein @ 1996-04-21 0:00 UTC (permalink / raw) Bradd W. Szonye <bradds@ix.netcom.com> wrote: > 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. What nonsense. Most programmers write the loop the first way out of habit and for consistency. Suppose we change the loop a little: for (size_t i = a; i < 10; i++) do_stuff(); versus for (size_t i = a; i != 10; i++) do_stuff(); Now the loops mean different things. Either might be correct, but the first is by far the more common. If the stack is trashed or the memory chips have failed, why do you want to get out of the loop? Why do you assume that getting out of the loop prematurely is better than not getting out of it at all? Suppose the loop is part of a sort. If you stay in it, the program will hang and the user will complain. If you exit it the program may continue and output erroneous information that causes costly errors. Defensive programming is important, but coding so you'll exit a loop even if the hardware fails has nothing to do with it. Michael M Rubenstein ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-21 0:00 ` Mike Rubenstein @ 1996-04-22 0:00 ` Tom Payne 1996-04-22 0:00 ` Peter Seebach 0 siblings, 1 reply; 177+ messages in thread From: Tom Payne @ 1996-04-22 0:00 UTC (permalink / raw) Mike Rubenstein (miker3@ix.netcom.com) wrote: : Bradd W. Szonye <bradds@ix.netcom.com> wrote: : : > 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. [...] : Defensive programming is important, but coding so you'll exit a loop : even if the hardware fails has nothing to do with it. I'm not sure that I agree with the fundamental premise behind defensive programming: "Don't make your program a sucker for bugs." [p. 45, Software Tools, Kernighan and Plauger] Granted, if its an embedded controller in a life-support system, I'd like every routine to make every effort to muddle through even in the presence of bizarre hardware faults, etc. In general programs, however, I'd like them to crash as soon as possible when something is wrong, and for that reason I've gone back to the i != 10 style for upper limits on for-loops. Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-22 0:00 ` Tom Payne @ 1996-04-22 0:00 ` Peter Seebach 0 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-22 0:00 UTC (permalink / raw) In article <4lgaeq$l1g@galaxy.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote: >Granted, if its an embedded controller in a life-support system, I'd >like every routine to make every effort to muddle through even in the >presence of bizarre hardware faults, etc. In general programs, however, >I'd like them to crash as soon as possible when something is wrong, and >for that reason I've gone back to the i != 10 style for upper limits >on for-loops. But that means it will keep going, possibly for a long time. Better to assert or print warnings. (I am a great fan of debugging messages; many of my programs will cheerfully produce a megabyte or minute or more of warnings and traces from normal operation. A lifesaver when something goes wrong.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
[parent not found: <JSA.96Feb16135027@organon.com>]
* Re: C/C++ knocks the crap out of Ada @ 1996-03-26 0:00 ` Ed Falis 1996-03-28 0:00 ` Kevin Cline 0 siblings, 1 reply; 177+ messages in thread From: Ed Falis @ 1996-03-26 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > > > BTW, what architectures does ObjectAda support, and will ObjectAda > > code compile largely unmodified with Gnat, and vice versa? > > A Thompson guy could better answer this. I would be surprised > if Gnat and ObjectAda didn't compile things with little or no > modification. Heck, I've taken large chuncks of VAX Ada and moved > them to Gnat with no changes. Of course, these did not have any > OS specific stuff in them. > Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel cross to 32 bit X86 this year. Various PowerPC and 68K cross early next year. My experience so far is that the ability to cross compile code developed on GNAT or ObjectAda is pretty good - the main issues are in a couple of areas: one or other of the front-ends is a bit stronger in "corners" of the language, availability of identical bindings, and application use of implementation defined pragmas (Unchecked_Union definitely comes to mind, per discussion on another thread). On the other hand, there are an awful lot of issues that we used to see with Ada 83 compilers that just aren't there any more, especially such things as vendor defined unsigned types, low-level operations on addresses, shift operations etc. And these latter issues have always been the real ugly ones I've seen - where client code is calling "vendor_x_system.ought_to_have_been_defined_in_the_standard;" and it has to be reorganized or changed in hundreds of places. Obviously this was poor design, but Ada 95 will still help with its more uniform treatment of these kinds of issues. - Ed Ed Falis Thomson Software falis@thomsoft.com (617) 221-7341 ======================================================== Ideological disarmament: a koan for the 21st century ======================================================== ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-26 0:00 ` C/C++ knocks the crap out of Ada Ed Falis @ 1996-03-28 0:00 ` Kevin Cline 1996-03-30 0:00 ` Jon S Anthony 0 siblings, 1 reply; 177+ messages in thread From: Kevin Cline @ 1996-03-28 0:00 UTC (permalink / raw) In article <31582A63.4BE9@east.thomsoft.com>, Ed Falis <falis@east.thomsoft.com> wrote: >Jon S Anthony wrote: >> >> In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: >> >> > BTW, what architectures does ObjectAda support, and will ObjectAda >> > code compile largely unmodified with Gnat, and vice versa? >> >> A Thompson guy could better answer this. I would be surprised >> if Gnat and ObjectAda didn't compile things with little or no >> modification. Heck, I've taken large chuncks of VAX Ada and moved >> them to Gnat with no changes. Of course, these did not have any >> OS specific stuff in them. >> > >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next >year. > Well, that means that today's ObjectAda would not solve my 1993 problem: writing a Motif application for SunOS 4.1.3, Solaris, and SGI IRIX. Some of you may be asking "Why did you use Ada given all these problems?" I used it because my DoD customer wanted me to. >My experience so far is that the ability to cross compile code developed >on GNAT or ObjectAda is pretty good - the main issues are in a couple of >areas: ... availability of identical bindings This problem alone is enough to disqualify Ada for development of medium-sized UNIX applications. Admittedly, until POSIX all UNIX systems appeared to be slightly different, even to C/C++ applications, but the differences were relatively minor, well known, and easily worked around. Different Ada bindings tend to (say) UNIX tend to be radically different and much more work is required to translate from one binding to another. -- Kevin Cline ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: C/C++ knocks the crap out of Ada @ 1996-03-30 0:00 ` Jon S Anthony 1996-04-01 0:00 ` Kevin Cline 0 siblings, 1 reply; 177+ messages in thread From: Jon S Anthony @ 1996-03-30 0:00 UTC (permalink / raw) In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, > >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel > >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next > >year. > > > > Well, that means that today's ObjectAda would not solve > my 1993 problem: writing a Motif application for SunOS 4.1.3, > Solaris, and SGI IRIX. Other than the GCC C compiler, what C compiler could do this now or in 1993? None. Of course, Gnat can do it now too. I am assuming here that you are talking about the fact that ObjectAda does not appear to support IRIX or SunOS (an obsolete OS...) > Some of you may be asking "Why did you use Ada given all these problems?" > I used it because my DoD customer wanted me to. What I'm wondering is, what the f**k your point is wrt to the situation today? > >My experience so far is that the ability to cross compile code developed > >on GNAT or ObjectAda is pretty good - the main issues are in a couple of > >areas: ... availability of identical bindings > > This problem alone is enough to disqualify Ada for development > of medium-sized UNIX applications. Admittedly, until POSIX all > UNIX systems appeared to be slightly different, even to C/C++ > applications, but the differences were relatively minor, well known, > and easily worked around. Different Ada bindings tend to (say) UNIX > tend to be radically different and much more work is required to > translate from one binding to another. I see you are _still_ the clueless wonder. Since Ada95 _portably_ interfaces with C, thin bindings give you everything you get with C (or C++). Now, this may not be all that high level or clean, but they are _exactly_ what the C hack uses. Ada bindings that are "radically different" (or even different...) are those which are _thick_ bindings - ones trying to hide the ugliness of the lowlevel C binding. Since you are a C guy, you apparently get along just fine with these lowlevel bindings and so should not be complaining about using the Ada _thin_ bindings to them - they are effectively identical!! They even _look_ pretty much the same. I'm building a Motif interface and building a couple custom widgets to go with it and the calls to the X, Xt and Motif toolkits look (for good or ill) virtually the same as a C version. So, just what _are_ you talking about? Hmmmm???? /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-30 0:00 ` Jon S Anthony @ 1996-04-01 0:00 ` Kevin Cline 1996-04-02 0:00 ` Lawrence Kirby 0 siblings, 1 reply; 177+ messages in thread From: Kevin Cline @ 1996-04-01 0:00 UTC (permalink / raw) In article <JSA.96Mar29195546@organon.com>, Jon S Anthony <jsa@organon.com> wrote: >In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >> >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, >> >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel >> >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next >> >year. >> > >> >> Well, that means that today's ObjectAda would not solve >> my 1993 problem: writing a Motif application for SunOS 4.1.3, >> Solaris, and SGI IRIX. > >Other than the GCC C compiler, what C compiler could do this now or in >1993? None. As usual, you missed the point, Jon. Different Ada-83 compiler vendors provided different bindings to key functionality like UNIX OS calls and X/Motif. Of course these bindings were proprietary. This was never a problem for C code. ANSI-C compilers have been available for every platform you can name for many years, so porting C code from one vendor's compiler to another was never a big problem. >What your point is wrt to the situation today? 1. I wanted to know if there was something I should have done differently back then. Apparently there wasn't. Ada-83 just sucked for non-embedded application development. 2. I wanted to know if the situation had improved. 3. I wanted to explain to Ada advocates why developing portable UNIX applications was impossible with Ada-83. >Since Ada95 _portably_ interfaces with C, >thin bindings give you everything you get with C (or C++). There is some information I can use. >Jon Anthony >Organon Motives, Inc. >1 Williston Road, Suite 4 >Belmont, MA 02178 With an attitude like Jon's, I would imagine this is a single-employee organization. -- Kevin Cline ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-04-01 0:00 ` Kevin Cline @ 1996-04-02 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 0 siblings, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-02 0:00 UTC (permalink / raw) In article <4jp388$d56@tpd.dsccc.com> kcline@sun132.spd.dsccc.com "Kevin Cline" writes: >As usual, you missed the point, Jon. Different Ada-83 compiler vendors >provided different bindings to key functionality like UNIX OS calls >and X/Motif. Of course these bindings were proprietary. > >This was never a problem for C code. ANSI-C compilers have been available >for every platform you can name for many years, so porting C code from >one vendor's compiler to another was never a big problem. ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. Unix calls are reasonably standardised for C through the likes of POSIX and X/Open which is natural because C is the core development language for the platform. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` Lawrence Kirby @ 1996-04-02 0:00 ` David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Lawrence Kirby 0 siblings, 2 replies; 177+ messages in thread From: David Emery @ 1996-04-02 0:00 UTC (permalink / raw) In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. > Unix calls are reasonably standardised for C through the likes of POSIX and > X/Open which is natural because C is the core development language for > the platform. > > -- > ----------------------------------------- > Lawrence Kirby | fred@genesis.demon.co.uk > Wilts, England | 70734.126@compuserve.com > ----------------------------------------- This is not exactly true. The POSIX.1 standard make extensive use of facilities in the ANSI C standard. Chapter 2 contains a list of library calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 contains C-specific facilities, that refine the behavior of some ANSI C library routines such as file stream IO. dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery @ 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton 1996-04-03 0:00 ` David Emery 1996-04-04 0:00 ` Lawrence Kirby 1 sibling, 2 replies; 177+ messages in thread From: The Right Reverend Colin James III @ 1996-04-02 0:00 UTC (permalink / raw) emery@grebyn.com (David Emery) posted with deletions: | In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: | | > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. | > Unix calls are reasonably standardised for C through the likes of POSIX and | > X/Open which is natural because C is the core development language for | > the platform. | > | > -- | > ----------------------------------------- | > Lawrence Kirby | fred@genesis.demon.co.uk | > Wilts, England | 70734.126@compuserve.com | > ----------------------------------------- | | This is not exactly true. The POSIX.1 standard make extensive use of | facilities in the ANSI C standard. Chapter 2 contains a list of library | calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 | contains C-specific facilities, that refine the behavior of some ANSI | C library routines such as file stream IO. | | dave Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` The Right Reverend Colin James III @ 1996-04-03 0:00 ` Bill Clinton 1996-04-03 0:00 ` David Emery 1 sibling, 0 replies; 177+ messages in thread From: Bill Clinton @ 1996-04-03 0:00 UTC (permalink / raw) To: cjames; +Cc: eanders The Right Reverend Colin James III wrote: > > emery@grebyn.com (David Emery) posted with deletions: > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To insult somebody and then post your "Voice" & "FAX" numbers does not reflect well on someone who claims to be a "priest" and possess a "doctorate". ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton @ 1996-04-03 0:00 ` David Emery 1996-04-03 0:00 ` The Right Reverend Colin James III 1 sibling, 1 reply; 177+ messages in thread From: David Emery @ 1996-04-03 0:00 UTC (permalink / raw) In article <3161447e.494168937@news.dimensional.com>, cjames@melchizedek.cec-services.com wrote: > emery@grebyn.com (David Emery) posted with deletions: > > | In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > | > | > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. > | > Unix calls are reasonably standardised for C through the likes of POSIX and > | > X/Open which is natural because C is the core development language for > | > the platform. > | > > | > -- > | > ----------------------------------------- > | > Lawrence Kirby | fred@genesis.demon.co.uk > | > Wilts, England | 70734.126@compuserve.com > | > ----------------------------------------- > | > | This is not exactly true. The POSIX.1 standard make extensive use of > | facilities in the ANSI C standard. Chapter 2 contains a list of library > | calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 > | contains C-specific facilities, that refine the behavior of some ANSI > | C library routines such as file stream IO. > | > | dave > > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Of course, if CJ Disease knew anything about POSIX, then he would be aware of the dependence that all POSIX standards, including the Ada binding, implicitly have on facilities in ANSI C. Furthermore, each POSIX binding has a chapter for language-specific facilities, Chapter 8. The POSIX/Ada binding Chapter 8 covers the interpretation of Text_IO facilities in a POSIX context. In particular, it defines the syntax and semantics of the FORM parameter for Text_IO.Open and Text_IO.Create, allowing such things as Append mode, access to POSIX file descriptors, etc. The implicit dependency that each POSIX standard has on "the mother document", POSIX.1, and its relationship to ANSI C, is particularly important for multi- language programming, since it defines, for most current POSIX implementations, the underlying mechanisms used by the various languages. At some level, both C and Ada runtime systems have to allocate memory. It is important that these allocation systems be interoperable (so memory allocated from C can be read in Ada, and vice versa), and a common approach to doing this is to build the Ada allocator on top of, or at least in cooperation with, C's malloc(). So, CJ Disease, go bite a mad cow... dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-03 0:00 ` David Emery @ 1996-04-03 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Dan Pop 0 siblings, 1 reply; 177+ messages in thread From: The Right Reverend Colin James III @ 1996-04-03 0:00 UTC (permalink / raw) emery@grebyn.com (David Emery) posted with deletions: | In article <3161447e.494168937@news.dimensional.com>, | cjames@melchizedek.cec-services.com wrote: | > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. | So, CJ Disease, go bite a mad cow... Poor pitiful Dave Emery is now reduced to name calling from Karl Grebyn's hangount. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-03 0:00 ` The Right Reverend Colin James III @ 1996-04-04 0:00 ` Dan Pop 0 siblings, 0 replies; 177+ messages in thread From: Dan Pop @ 1996-04-04 0:00 UTC (permalink / raw) In <31620b2a.545029571@news.dimensional.com> cjames@melchizedek.cec-services.com (The Right Reverend Colin James III) writes: >emery@grebyn.com (David Emery) posted with deletions: > >| In article <3161447e.494168937@news.dimensional.com>, >| cjames@melchizedek.cec-services.com wrote: > >| > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > >| So, CJ Disease, go bite a mad cow... > >Poor pitiful Dave Emery is now reduced to name calling from Karl >Grebyn's hangount. And this piece of bullshit clearly relates to C, C++ and Ada. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III @ 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` David Emery 1996-04-05 0:00 ` Robert Dewar 1 sibling, 2 replies; 177+ messages in thread From: Lawrence Kirby @ 1996-04-04 0:00 UTC (permalink / raw) In article <emery-0204960656230001@line030.nwm.mindlink.net> emery@grebyn.com "David Emery" writes: >In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > >> ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. >> Unix calls are reasonably standardised for C through the likes of POSIX and >> X/Open which is natural because C is the core development language for >> the platform. > >This is not exactly true. The POSIX.1 standard make extensive use of >facilities in the ANSI C standard. Chapter 2 contains a list of library >calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 >contains C-specific facilities, that refine the behavior of some ANSI >C library routines such as file stream IO. ANSI C defines the ANSI standard library calls. While UNIX(tm) validation may require these that is down to the UNIX and from that the POSIX specification, not the ANSI standard: there is nothing in the ANSI standard that states the UNIX system interface must be one thing or another, rather it is the UNIX standards that define the UNIX system interface with reference to the ANSI C standard. It may be a fine point but it is important. UNIX existed before ANSI C. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-04 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` David Emery 1996-04-06 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: David Emery @ 1996-04-05 0:00 UTC (permalink / raw) In article <828632277snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: ... > it is the UNIX standard that define the UNIX system interface with > reference to the ANSI C standard. ... Exactly so, POSIX.1 depends on ANSI C, but the converse is NOT true. dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` David Emery @ 1996-04-06 0:00 ` Lawrence Kirby 0 siblings, 0 replies; 177+ messages in thread From: Lawrence Kirby @ 1996-04-06 0:00 UTC (permalink / raw) In article <emery-0404962003250001@line084.nwm.mindlink.net> emery@grebyn.com "David Emery" writes: >In article <828632277snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > >... >> it is the UNIX standard that define the UNIX system interface with >> reference to the ANSI C standard. >... >Exactly so, POSIX.1 depends on ANSI C, but the converse is NOT true. True, but I don't think the converse was under discussion. POSIX.1 depends (if you like) on ANSI C but ANSI C doesn't define POSIX.1. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` David Emery @ 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Peter Seebach 1 sibling, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) Lawrence said "ANSI C defines the ANSI standard library calls. While UNIX(tm) validation may require these that is down to the UNIX and from that the POSIX specification, not the ANSI standard: there is nothing in the ANSI standard that states the UNIX system interface must be one thing or another, rather it is the UNIX standards that define the UNIX system interface with reference to the ANSI C standard." Unix validation????? Unix standards????? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Peter Seebach 1 sibling, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-05 0:00 UTC (permalink / raw) In article <dewar.828704810@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Lawrence said > >"ANSI C defines the ANSI standard library calls. While UNIX(tm) validation >may require these that is down to the UNIX and from that the POSIX >specification, not the ANSI standard: there is nothing in the ANSI standard >that states the UNIX system interface must be one thing or another, rather >it is the UNIX standards that define the UNIX system interface with >reference to the ANSI C standard." > >Unix validation????? > >Unix standards????? Certainly. In order for an OS to be able to call itself UNIX(tm) it must be validated again standards such as POSIX and SPEC1170. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Peter Seebach 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) "Certainly. In order for an OS to be able to call itself UNIX(tm) it must be validated again standards such as POSIX and SPEC1170." There is no official validation procedure for POSIX, and in any case Unix does not have to support POSIX (almost no unixes to day are fully POSIX compliant, I am not sure that *any* are 100% complaint). I do not know what SPEC1170 is??? Maybe you are using "validation" in some odd non-standard sense?? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 0 siblings, 2 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-06 0:00 UTC (permalink / raw) In article <dewar.828757565@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"Certainly. In order for an OS to be able to call itself UNIX(tm) it must >be validated again standards such as POSIX and SPEC1170." >There is no official validation procedure for POSIX, and in any case >Unix does not have to support POSIX (almost no unixes to day are >fully POSIX compliant, I am not sure that *any* are 100% complaint). Well, then what precisely did the Linux people use to base their recent announcement on? I suppose the US government departments that require POSIX compliant OS's are just flipping coins? >I do not know what SPEC1170 is??? *sigh* It's a vast list of basically every function ever offered by a Unix like environment, in one vast spec. It's at least a few months old, and you can look it up in bookstores on CD-ROM. >Maybe you are using "validation" in some odd non-standard sense?? Maybe you're just assuming that C and Unix haven't develope since 1983? -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Peter Seebach @ 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 1 sibling, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-06 0:00 UTC (permalink / raw) Speaking of SPEC1170, Peter said "*sigh* It's a vast list of basically every function ever offered by a Unix like environment, in one vast spec. It's at least a few months old, and you can look it up in bookstores on CD-ROM. " Yes, I tracked it down, but not in my list of standards. As far as I can tell this is neither a national or international standard, just some informally agreed on list. If there is a standard, can someone give the reference. Also if it is a standard, is there indeed a formal validation procedure? If so, can someone give the reference for this. Peter, I would find specific answers to these questions more infomative than sighs. Yes, I know that Unix has advanced, but has it really advanced to the point of being standardized and having formal certification/validation procedures. I certainly thought not, and that is what started this thread after all! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Philip Brashear 1996-04-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Philip Brashear @ 1996-04-16 0:00 UTC (permalink / raw) As regards POSIX and validation, I believe Robert (Dewar) said that there is no validation suite/process for POSIX. However, in mid-1991, Jim Hall of the (U.S.) National Institute of Standards and Technology's Computer Systems Laboratory announced a conformance testing policy for POSIX (FIPS 151-1, which was based upon IEEE 1003.1-1988. (I do not know if there have been updates.) The stes suite was developed by NIST/CSL and was "based on the test assertions specified by the IEEE 1003.3 working group on test methods." This is taken from POSIX Tracking Report, a quarterly report sponsored by Digital Equipment Corportation. Perhaps someone should check on the currency of this validation process, but there certainly was a validation suite and process for POSIX systems entering the U.S. Government's inventory. Phil Brashear CTA INCORPORATED ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Philip Brashear @ 1996-04-16 0:00 ` Robert Dewar 1996-04-19 0:00 ` Chuck Karish 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) Phil said "Perhaps someone should check on the currency of this validation process, but there certainly was a validation suite and process for POSIX systems entering the U.S. Government's inventory." IN fact later posts to CLA make it clear that not only is there such a testing process, but there is now a standardized suite (the latter development being more recent). ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Chuck Karish 0 siblings, 0 replies; 177+ messages in thread From: Chuck Karish @ 1996-04-19 0:00 UTC (permalink / raw) In article <dewar.829675437@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >IN fact later posts to CLA make it clear that not only is there such >a testing process, but there is now a standardized suite (the latter >development being more recent). The FIPS 151-1 certification program used a NIST-developed test suite that was based on Draft 10 of the POSIX.3.1 test methods standard. The FIPS 151-2 certification program, which tests to POSIX.1-1990 versus the eariler program's POSIX.1-1988, uses a later version of the same test suite that was updated to use test methods from the adopted version of the test methods standard, which is called IEEE Std 2003.1-1992. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` Peter Seebach 1996-04-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-05 0:00 UTC (permalink / raw) In article <dewar.828704810@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Unix standards????? You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the US govt. will not use Win NT because of, because it doesn't match the spec they've selected. Begging pardon, but why does an obviously well-educated person feel the need to use multiple question marks on a query about something which has been common knowledge for at least a couple of years? I've been seeing POSIX books for quite some time. It seems as though you're a bit out of touch with the Unix world; you were amazed that Linux killed a program which did read(fd, buf, nbytes); when buf wasn't large enough for nbytes, simply because the file didn't have nbytes left, and had less data than buf could hold. (This came up in a previous discussion.) You were surprised when people pointed out that standard C allows an implementation to catch and prohibit attempts to modify the internals of a FILE, and that in fact, code which does so has ceased to be legal C. You are constantly amazed by claims about standards for C or Unix which may be a year or more old. I am getting the impression that you've not really taken the time to keep up with the standards community, and have been complaining about the excessive chumminess with the compiler that used to be considered normal and healthy in C. It's not, anymore. Linus Torvalds, a man who has probably written a fair amount of low-level code in C, some of it terriyingly optimized, was recently seen flaming people for advocating unportable tricks in C - tricks which work on *every* major C implementation currently in use. I can certainly understand your position; I've seen C advocates talk about what Ada 83 did, and comparing it with C 89. But it's not fair when they do it, and it's not fair when you do it, either, no matter *how* good you are. (And I must admit, by all accounts, you're quite good.) Sometime, take a weekend or so to catch up with how modern C is written, what the standards do and don't guarantee, and look at some of the checks, warnings, and analyses available from modern C programming tools. I think you'll find that C has matured quite a lot as a programming language since, say, 1983. Most of your complaints about C and Unix match up strongly with the frustrations I had getting things to run on an SVR4/ANSI C environment in 1990 or so, when C was only a year old as a standardized language, and no one was really writing for it yet. That was quite a while ago for this industry; right now, I can write "portable" programs and expect them to work on every commercial Unix, and every free Unix. I don't have to think very hard to do it; I just write code the way I would anyway, and it magically works. I occasionally have to put in some sort of sop for a broken system, but rarely; they're getting rarer, and I don't expect to even think about it in another couple of years. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Peter Seebach @ 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Chuck Karish 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) "You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the US govt. will not use Win NT because of, because it doesn't match the spec they've selected." But none of POSIX, Spec 1170, nor X/Open have official validatoin suites and testing procedures as far as I know, and certainly very few Unix implemntations are 100% compliant with POSIX (very few versions of Unix even claim to support Draft 10 of Posix threads). X/Open is not even a standard as far as I know. Perhaps you use standard in a lose informal sense. I am quite aware that the behavior of read in Linux is ANSI compliant (dspite your memory, I never claimed otherwise). I just noted that this is incompatible with most traditional impleemntations and causes portability problems. I find this all quite odd. There is no standard for Unix, so ohw could there possibly be formal validation procedures. POSIX has nothing to do with Unix (you can have Unix without POSIX -- there are many examples, and POSIX without Unix -- e.g. as in NT, despite your claims about NT, NT is in fact petty well Posix compliant, and will pass the posix test suite as far as I know [that test suite as far as I know still has not been adopted as an official test suite by NIST, but perhaps I am out of date, if so please inform) I actually know ANSI C very well, but I do not find this knowledge as useful as the Microsoft book on C runtime routines which shows compatibilities between various systems. There are things in ANSI which you cannot use safely and portably, and there are things you can use saetly and portably that are not in ANSI. This will change over time, but that is my experience to date. Anyway, can someone who really knows the score here tell us: Which of Unix, Posix, Spec 1170, X/Open have approved national and/or international standards. Of this subset, which have official validation procedure run by NIST or some other similar body? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-06 0:00 ` Lawrence Kirby 1996-04-06 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1 sibling, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-06 0:00 UTC (permalink / raw) In article <dewar.828757752@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." > >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). X/Open is not even >a standard as far as I know. I assume that there are specific parts of POSIX required for validation, not all of it. Parts of it are still very much under development. >I am quite aware that the behavior of read in Linux is ANSI compliant >(dspite your memory, I never claimed otherwise). read() isn't defined by ANSI C, in this context it is a POSIX.1 function. >I just noted that this >is incompatible with most traditional impleemntations and causes >portability problems. You could take the view that is shows up portability problems in code in a reasonably tracable way and, as such, is a positive feature! :-) >I actually know ANSI C very well, but I do not find this knowledge >as useful as the Microsoft book on C runtime routines which shows >compatibilities between various systems. There are things in ANSI >which you cannot use safely and portably, I'm curious as to the sort of things you are thinking of. and there are things you >can use saetly and portably that are not in ANSI. This will change >over time, but that is my experience to date. >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are national/international standards but are something you have to conform to if you want to call your OS UNIX(tm). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Lawrence Kirby @ 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Chuck Karish 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-06 0:00 UTC (permalink / raw) "Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are national/international standards but are something you have to conform to if you want to call your OS UNIX(tm). " This is plain wrong! There are lots of unixes out there that call themselves UNIX and do not conform exactly to SPEC1170. Consider for example, also answering your question about ANSI being a misleadng guide to portability, the return type of sprintf. I don't have SPEC1170 on hand, but it is a good guess that it is ANSI compliant here (return type int), but BSD heritage unices (like SunOS) return char *. "have to conform to" and prey who enforces this rule? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Robert Dewar @ 1996-04-07 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` halvin 1996-04-12 0:00 ` Chuck Karish 1 sibling, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828846122@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >"Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are >national/international standards but are something you have to conform to >if you want to call your OS UNIX(tm). >" > >This is plain wrong! There are lots of unixes out there that call themselves >UNIX and do not conform exactly to SPEC1170. No, they call themselves Unix. They *cannot* call themselves UNIX(tm). >Consider for example, also answering your question about ANSI being >a misleadng guide to portability, the return type of sprintf. I don't >have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >here (return type int), but BSD heritage unices (like SunOS) return >char *. In any ANSI compiler/library sprintf returns int. Tell me of any modern system which doesn't make the correct functionality available in a library, if not the default. These days this is a non-issue with regards to portability (even considering Sun systems). >and prey who enforces this rule? X/Open own the UNIX trademark and have the legal right to enforce it. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach ` (2 more replies) 0 siblings, 3 replies; 177+ messages in thread From: halvin @ 1996-04-10 0:00 UTC (permalink / raw) Lawrence Kirby <fred@genesis.demon.co.uk> writes: >>Consider for example, also answering your question about ANSI being >>a misleadng guide to portability, the return type of sprintf. I don't >>have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >>here (return type int), but BSD heritage unices (like SunOS) return >>char *. >In any ANSI compiler/library sprintf returns int. Tell me of any modern >system which doesn't make the correct functionality available in a library, >if not the default. These days this is a non-issue with regards to >portability (even considering Sun systems). this might be slightly off-topic, but isn't there a difference between the ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version returns 0 on success and EOF on failure -- but the POSIX version returns the number of characters printed, or a negative number to indicate failure. so which behavior should one expect in an ANSI C application that happens to run in a POSIX-compliant environment? a student stumbled upon this issue, and i didn't really have an answer, as i had thought that POSIX was a proper superset of ANSI C. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin @ 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgjrc$4d@news.nyu.edu>, halvin <halvin@acf4.nyu.edu> wrote: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. ANSI fprintf returns # bytes written also. >so which behavior should one expect in an ANSI C application that happens >to run in a POSIX-compliant environment? a student stumbled upon this issue, >and i didn't really have an answer, as i had thought that POSIX was a proper >superset of ANSI C. Assuming that they disagreed, an ANSI C application would expect the ANSI behavior, and a POSIX application would expect the POSIX behavior. How you tell which you are? Simple! If you use extensions of POSIX, you're POSIX. But since they agree, it's a moot point. :) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach @ 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 177+ messages in thread From: Dan Pop @ 1996-04-11 0:00 UTC (permalink / raw) In <4kgjrc$4d@news.nyu.edu> halvin@acf4.nyu.edu (halvin) writes: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. This is what you get for relying on your (faulty) memory when dealing with standards issues. From the ANSI C standard: The fprintf function returns the number of characters transmitted, or a negative value if an output error occurred. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop @ 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 177+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kgjrc$4d@news.nyu.edu>, halvin <halvin@acf4.nyu.edu> wrote: >Lawrence Kirby <fred@genesis.demon.co.uk> writes: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. POSIX.1 defers to the C Standard for the specification of fprintf(). Where POSIX.1 does add requirements on the behavior of C Standard features, the intent is always to enforce a more specific requirement without violating the C Standard. Any conflict between POSIX.1 and Standard C is unintentional and is considered an error to be fixed by the POSIX committees. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <dewar.828846122@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are >national/international standards but are something you have to conform to >if you want to call your OS UNIX(tm). >" > >This is plain wrong! There are lots of unixes out there that call themselves >UNIX and do not conform exactly to SPEC1170. Not wrong, just incomplete. The trade mark owner (X/Open) has stated the requirements for use of the word. This includes, for new systems, demonstration of conformance to the requirements of the XPG4 UNIX profile, a formalization of Spec 1170. There are special arrangements for vendors met the requirements for use of the UNIX name under agreements with previous owners of the trade mark (AT&T, USL, Novell). >Consider for example, also answering your question about ANSI being >a misleadng guide to portability, the return type of sprintf. I don't >have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >here (return type int), but BSD heritage unices (like SunOS) return >char *. The list of interesting UNIX-like porting targets that don't support both Standard C and POSIX.1 gets shorter every year. I don't feel guilty at all calling code portable even though I know it would not compile on a Version 7 UNIX system. >"have to conform to" > >and prey who enforces this rule? The market, ultimately. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Chuck said "The list of interesting UNIX-like porting targets that don't support both Standard C and POSIX.1 gets shorter every year. I don't feel guilty at all calling code portable even though I know it would not compile on a Version 7 UNIX system. " Of course GCC has a much more agressive view of portability, but it certainly would be nice to see more standardization here, and for example, it sure would be nice if everyone's make utility implemented at least vaguely the same semantics! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829345962@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Of course GCC has a much more agressive view of portability, but it >certainly would be nice to see more standardization here, I don't understand. Do you have portability problems when you use gcc in ANSI mode? >and for >example, it sure would be nice if everyone's make utility implemented >at least vaguely the same semantics! POSIX.2 specifies a well-defined set of semantics for make. XPG4 picks up the POSIX.2 spec and adds some extensions that are also guaranteed to be supported on conforming systems (see www.xopen.co.uk for a list; look for XPG4 BASE 95 branded products). That doesn't solve the problem of having to import code whose maintainers choose to use extensions from, for example, gnu make, BSD make, or imake. If you're maintaining a diverse code base you may have to keep several versions of make on hand. At least for these examples the source is readily available. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach 1996-04-15 0:00 ` Chuck Karish 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) Chuck asked (replying to me): ">Of course GCC has a much more agressive view of portability, but it >certainly would be nice to see more standardization here, I don't understand. Do you have portability problems when you use gcc in ANSI mode?" Yes we do. gcc takes the view that it should work in all common C environments (i.e. those in use today), whether or not they are ANSI compliant. Early on when I started writing some C runtime code for GNAT (or more accurately interfacing to standard C runtime routines), I followed the ANSI standard. As I mentioned before the particular example I remember is that I used the return value of sprintf, assuming it returned int. My code worked on several systems, and then failed on SunOS, and I was told -- oh yes, everyone knows that you cannot use the returned value of sprintf. Now of course it is the case that there must be available on SunOS a conforming library, but we require gcc to work with all commonly used environments without any special fiddling in choosing libraries. That's what I meant by saying that gcc has a more strenuous view of portability. Chuck's view of portablity seems to be "use ANSI, and too bad if it doesn't work for you". That's fair enough but it is not the attitude that gcc takes, where we are aiming for much more general portability. Over time, the two views will converge but not yet. I have found the Microsoft runtime reference manual very useful. For each function it indicates ANSI/Unix/Xenix/DOS/OS2 compatibility. There are many cases where the ANSI box is checked and other boxes are not. For instance, unlink is compatible with all systems but is NOT ANSI, on the other hand delete, which is the ANSI version, is not available on all systems. It just depends on what you are trying to achieve! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Peter Seebach 1996-04-13 0:00 ` Robert Dewar 1996-04-15 0:00 ` Chuck Karish 1 sibling, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829399701@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >indicates ANSI/Unix/Xenix/DOS/OS2 compatibility. There are many cases >where the ANSI box is checked and other boxes are not. For instance, >unlink is compatible with all systems but is NOT ANSI, on the other >hand delete, which is the ANSI version, is not available on all systems. delete() is not ANSI. remove() is ANSI. I have never seen a system that didn't offer it, since the 3b1. It's certainly trivial to write. (A good patch for portability is to write standard code, and have a set of conditionally built modules to provide the standard functions in terms of the not-standard but available on all old systems functions.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Peter Seebach @ 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) Peter said: "delete() is not ANSI. remove() is ANSI. I have never seen a system that didn't offer it, since the 3b1. It's certainly trivial to write. (A good patch for portability is to write standard code, and have a set of conditionally built modules to provide the standard functions in terms of the not-standard but available on all old systems functions.)" Oops, that's right, it is indeed remove I meant (I don't know it because I don't use it -- I don't use it because the Microsoft book says it is not implemented in some systems). On the other hand, that same book says that unlink is implemented in all systems, so clearly at least for the moment unlink is safer to use if you are aiming at maximum portability. Rememerb that gcc is targeted to more than 300 different C library environments, and you want to absolutely minimize conditional stuff. That's what I meant by having a strenuous view of portability. I would rather guess that Peter is pretty Unix oriented, and of course we are trying for a wider scope of portability than Unix! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 1 sibling, 0 replies; 177+ messages in thread From: Lawrence Kirby @ 1996-04-14 0:00 UTC (permalink / raw) In article <dewar.829446681@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Peter said: > >"delete() is not ANSI. remove() is ANSI. I have never seen a system that >didn't offer it, since the 3b1. It's certainly trivial to write. (A good >patch for portability is to write standard code, and have a set of >conditionally built modules to provide the standard functions in terms >of the not-standard but available on all old systems functions.)" > >Oops, that's right, it is indeed remove I meant (I don't know it because >I don't use it -- I don't use it because the Microsoft book says it is >not implemented in some systems). On the other hand, that same book says >that unlink is implemented in all systems, so clearly at least for the >moment unlink is safer to use if you are aiming at maximum portability. remove() is the ANSI defined function, unlink() is the Unix/POSIX defined function. I guess comp.lang.ada readers would be more interested in the latter as far as this thread is concerned but comp.lang.c readers should be using remove() unless they have a good reason not to. I believe the book is misleading you. I wonder though if Ada provides all of the functionality that the C standard library provides and if not whether the Ada POSIX bindings redress the holes. >Rememerb that gcc is targeted to more than 300 different C library >environments, and you want to absolutely minimize conditional stuff. gcc has been ported to environments over many years which have little or no ANSI C support. The situation now is somewhat different, not least because you can use gcc/glibc on many systems. By the sound of it GNAT is doing a similar service for up-to-date Ada. The considerations are different for code written now. >That's what I meant by having a strenuous view of portability. I would >rather guess that Peter is pretty Unix oriented, and of course we are >trying for a wider scope of portability than Unix! In which case you definitely want the ANSI C remove() over the Unix/POSIX unlink(). The only systems where unlink() is more likely to occur are very old systems since unlink() existed first. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby @ 1996-04-15 0:00 ` Chuck Karish 1 sibling, 0 replies; 177+ messages in thread From: Chuck Karish @ 1996-04-15 0:00 UTC (permalink / raw) In article <dewar.829446681@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >On the other hand, that same book says >that unlink is implemented in all systems, so clearly at least for the >moment unlink is safer to use if you are aiming at maximum portability. >Rememerb that gcc is targeted to more than 300 different C library >environments, and you want to absolutely minimize conditional stuff. >That's what I meant by having a strenuous view of portability. I would >rather guess that Peter is pretty Unix oriented, and of course we are >trying for a wider scope of portability than Unix! But unlink() is a UNIX system call that was also implemented in many other environments. unlink() on UNIX and POSIX systems is only guaranteed to work if the argument is the name of a regular file; on many systems, unlink() fails for directories. The rationale for ANSI C says that remove() was meant to be a generalized re-casting of the unlink() functionality, free of UNIX filesystem terminology ("link"). Implementations of remove() are allowed (but not required!) to do the right thing no matter what type of file they're used on. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach @ 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-15 0:00 UTC (permalink / raw) In article <dewar.829399701@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Chuck asked (replying to me): > >">Of course GCC has a much more agressive view of portability, but it >>certainly would be nice to see more standardization here, > >I don't understand. Do you have portability problems when you use >gcc in ANSI mode?" >Yes we do. gcc takes the view that it should work in all common C >environments (i.e. those in use today), whether or not they are ANSI >compliant. Early on when I started writing some C runtime code for >GNAT (or more accurately interfacing to standard C runtime routines), >I followed the ANSI standard. As I mentioned before the particular >example I remember is that I used the return value of sprintf, >assuming it returned int. My code worked on several systems, and >then failed on SunOS, and I was told -- oh yes, everyone knows that >you cannot use the returned value of sprintf. Now of course it is >the case that there must be available on SunOS a conforming library, >but we require gcc to work with all commonly used environments without >any special fiddling in choosing libraries. While I applaud the attempt to make gcc work even with broken C libraries, I don't think it's particularly productive to describe gcc as being flawed when this turns out not to be possible. >That's what I meant by >saying that gcc has a more strenuous view of portability. Chuck's >view of portablity seems to be "use ANSI, and too bad if it doesn't >work for you". That's not the way I work and it's not the way I've described my approach in this thread. >That's fair enough but it is not the attitude that >gcc takes, where we are aiming for much more general portability. There are limits to what can be accomplished this way. ANSI C and traditional C are different languages. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-15 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) "There are limits to what can be accomplished this way. ANSI C and traditional C are different languages." True, but the coding standards of GCC require remaining compatible with both, and this is certainly achievable in practice. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-16 0:00 UTC (permalink / raw) In article <dewar.829628593@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"There are limits to what can be accomplished this way. ANSI >C and traditional C are different languages." > >True, but the coding standards of GCC require remaining compatible with >both, and this is certainly achievable in practice. It will always be an uphill battle to provide Standard C semantics in programs that will be linked against traditional C libraries. Luckily (?) the old-style libraries no longer present a moving target for developers, so workarounds for their brokenness/archaic charm/whatever will stick once they're implemented. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) Chuck said "It will always be an uphill battle to provide Standard C semantics in programs that will be linked against traditional C libraries." Not such an uphill battle at all. Just a matter of learning what you can and cannot do. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Robert Dewar 1 sibling, 2 replies; 177+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." Incorrect premise: Windows NT does conform to POSIX.1 and the US Government does buy it as a FIPS 151-2 conforming system. >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, Then you don't know very much about standards conformance certification. The US Department of Commerce has an official test suite for FIPS 151-2 conformance that is a good indicator of POSIX.1-1990 conformance. X/Open has test suites that cover POSIX.1 and most of the UNIX extensions to it that make up SPEC 1170. This set of tests make up the official indicators of conformance to the XPG4 UNIX profile, which is what Spec 1170 describes. >and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). Claims of POSIX conformance are supportable when one makes the reasonable next step of specifying which POSIX standards one is referring to. I know of at least two UNIX implementations that support POSIX.1c threads. >X/Open is not even a standard as far as I know. X/Open is a corporation. XPG4 is a specification that has all the properties of a standard except ownership by a quasi-governmental organization. >I find this all quite odd. There is no standard for Unix, so ohw could >there possibly be formal validation procedures. XPG4 is a standard for UNIX. The owner of XPG4 spells out the formal validation procedures. Check them out on their web site: http://www.xopen.co.uk/public/test >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. If you include privately-controlled standards bodies (X/Open), all of them. >Of this subset, which have official validation procedure run by NIST >or some other similar body? With the same proviso, all of them. Of the many POSIX standards, only POSIX.1-1990 and POSIX.2-1992 have usable validation test suites. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Robert Dewar 1 sibling, 2 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kkbk7$hv8@nntp.Stanford.EDU>, Chuck Karish <karish@pangea.Stanford.EDU> wrote: >In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >>"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >>US govt. will not use Win NT because of, because it doesn't match the spec >>they've selected." > >Incorrect premise: Windows NT does conform to POSIX.1 and the >US Government does buy it as a FIPS 151-2 conforming system. It does? You mean under NT, I could, say, disable the console echo by making suitable changes to a ``struct termios'', and pass it to tcsetattr()? Or send a SIGTSTP signal to the foreground process group from the controlling terminal? Wow... -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Tom Griest 1 sibling, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkru5INN71j@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >In article <4kkbk7$hv8@nntp.Stanford.EDU>, >Chuck Karish <karish@pangea.Stanford.EDU> wrote: >>Incorrect premise: Windows NT does conform to POSIX.1 and the >>US Government does buy it as a FIPS 151-2 conforming system. > >It does? You mean under NT, I could, say, disable the console echo by making >suitable changes to a ``struct termios'', and pass it to tcsetattr()? >Or send a SIGTSTP signal to the foreground process group from the controlling >terminal? Wow... Neither POSIX.1-1990 nor FIPS 151-2 requires that a conforming system support the POSIX.1 general terminal interface. Windows NT 3.51 does not do so. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-12 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-12 0:00 UTC (permalink / raw) In article <4km8el$3he@nntp.Stanford.EDU>, Chuck Karish <karish@pangea.Stanford.EDU> wrote: >Neither POSIX.1-1990 nor FIPS 151-2 requires that a conforming >system support the POSIX.1 general terminal interface. Windows >NT 3.51 does not do so. Right. And the ANSI/ISO C standard doesn't require that a program that has more than one instance of an object that is 32K long be translated by a conforming implementation. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Chuck Karish @ 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Tom Griest @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkru5INN71j@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: >In article <4kkbk7$hv8@nntp.Stanford.EDU>, >Chuck Karish <karish@pangea.Stanford.EDU> wrote: >>In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >>>"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >>>US govt. will not use Win NT because of, because it doesn't match the spec >>>they've selected." >> >>Incorrect premise: Windows NT does conform to POSIX.1 and the >>US Government does buy it as a FIPS 151-2 conforming system. > >It does? You mean under NT, I could, say, disable the console echo by making >suitable changes to a ``struct termios'', and pass it to tcsetattr()? >Or send a SIGTSTP signal to the foreground process group from the controlling >terminal? Wow... I know the Government is buying NT in quantity. Although I have not personally used either of these two Posix features on NT, both are documented in the SDK under the Posix directory. The major problem with Posix on NT is that you don't get Posix functionality and windows funtionality in the same process. But as far as running Posix applications, my limited experience is that they do work fine. -Tom ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Tom Griest @ 1996-04-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Tom said "I know the Government is buying NT in quantity. Although I have not personally used either of these two Posix features on NT, both are documented in the SDK under the Posix directory. The major problem with Posix on NT is that you don't get Posix functionality and windows funtionality in the same process. But as far as running Posix applications, my limited experience is that they do work fine." Rather a horrible restriction, don't you think? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-22 0:00 ` Mike McCarty 1 sibling, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Chuck said "With the same proviso, all of them. Of the many POSIX standards, only POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." Fair enough, but I meant national or international standards when I asked my question. By the way, which Unices are 100% posix threads compliant (you ssaid you knew). How does the POSIX testing deal with the issue of test profiles, Dave, (Emery), can you clarify that procedure? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 1996-04-22 0:00 ` Mike McCarty 1 sibling, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829345812@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Chuck said >"With the same proviso, all of them. Of the many POSIX standards, only >POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." > >Fair enough, but I meant national or international standards when I asked >my question. I fail to see a practical distinction between a national or international standard like POSIX.5 and an industry standard like XPG4. For both types of specifications a certified system provides behavior that a programmer can count on. X/Open branding is used as a qualification for procurement purposes by some governmental agencies and large commercial customers, just as FIPS certification is used by the US Government. >By the way, which Unices are 100% posix threads compliant (you ssaid you >knew). I said that several implementations claim to support POSIX.1c. There is no mechanism now in place for them to demonstrate conformance. The examples I had in mind (there may well be others) are Solaris 2.5 and Digital UNIX 1.0 (aka OSF/1 4.0). >How does the POSIX testing deal with the issue of test profiles, Dave, >(Emery), can you clarify that procedure? What do you mean by a "test profile"? I'm not familiar with this usage. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` David Emery 0 siblings, 0 replies; 177+ messages in thread From: David Emery @ 1996-04-13 0:00 UTC (permalink / raw) In article <4knq1l$g6d@nntp.Stanford.EDU>, karish@pangea.Stanford.EDU (Chuck Karish) wrote: ... > I said that several implementations claim to support POSIX.1c. There > is no mechanism now in place for them to demonstrate conformance. > > The examples I had in mind (there may well be others) are Solaris 2.5 > and Digital UNIX 1.0 (aka OSF/1 4.0). > ... > > Chuck Karish karish@mindcraft.com > (415) 323-9000 x117 karish@pangea.stanford.edu Does Digitial Unix 1.0 OSF/1 4.0 support BOTH POSIX threads (1003.1c) and DCE threads (nee P1003.4b D4)? There are some significant differences between DCE threads and the final POSIX standard... dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish @ 1996-04-22 0:00 ` Mike McCarty 1996-04-22 0:00 ` David Emery 1 sibling, 1 reply; 177+ messages in thread From: Mike McCarty @ 1996-04-22 0:00 UTC (permalink / raw) In article <dewar.829345812@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: )Chuck said ) )"With the same proviso, all of them. Of the many POSIX standards, only )POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." ) )Fair enough, but I meant national or international standards when I asked )my question. ) )By the way, which Unices are 100% posix threads compliant (you ssaid you )knew). Presumably, all of them. Note that the standard does -not- require things to be implemented, for an implementation to be compliant. And threads are part of the "optional" portion of Posix. Mike -- ---- char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I don't speak for DSC. <- They make me say that. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-22 0:00 ` Mike McCarty @ 1996-04-22 0:00 ` David Emery 0 siblings, 0 replies; 177+ messages in thread From: David Emery @ 1996-04-22 0:00 UTC (permalink / raw) In article <4lgube$dla@sun001.spd.dsccc.com>, jmccarty@sun1307.spd.dsccc.com (Mike McCarty) wrote: ... > )By the way, which Unices are 100% posix threads compliant (you ssaid you > )knew). > > Presumably, all of them. Note that the standard does -not- require > things to be implemented, for an implementation to be compliant. And > threads are part of the "optional" portion of Posix. > > Mike > -- > ---- > char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} > > I don't speak for DSC. <- They make me say that. OK, let me rephrase the question: Which vendors claim conformance to the optional features of POSIX that were originally defined in P1003.4a/POSIX.1c (i.e. which vendors claim to have IMPLEMENTED POSIX threads), where conformace is defined as supporting the appropriate option, and meeting the requirements of the standard when the option is supported? dave p.s. Informally, an implementation which claims to be 'threads compliant' by stating that the threads option is not supported is pretty bogus!! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) [not found] <JSA.96Feb16135027@organon.com> 1996-03-26 0:00 ` C/C++ knocks the crap out of Ada Ed Falis @ 1996-04-06 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Dan Pop @ 1996-04-06 0:00 UTC (permalink / raw) In <dewar.828757752@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." > >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). X/Open is not even >a standard as far as I know. The name of the standard is actually XPG 4.2 (it was formerly known as Spec 1170). X/Open is the name of the organization that certifies that a certain OS complies to this standard. >I am quite aware that the behavior of read in Linux is ANSI compliant >(dspite your memory, I never claimed otherwise). This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI compliant for the simple reason that the ANSI/ISO C standard does NOT define such a function. read may (or may not) be POSIX, SVID or XPG compliant. >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. For an operating system to be allowed to be officially named UNIX(TM) it has to be validated by X/Open, the current owner of the UNIX brand. This validation is based on compliance to XPG 4.2. I don't know the details. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Dan Pop @ 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach ` (2 more replies) 0 siblings, 3 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) Dan Pop "This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI compliant for the simple reason that the ANSI/ISO C standard does NOT define such a function. read may (or may not) be POSIX, SVID or XPG " Dan, you miss the point, of course read in Linux is compliant with the ANSI standard, precisely because this standard does NOT specify any required behavior for read, and permits the addition of such functions. How could you possibly claim that read could be non-compliant with ANSI (something is either compliant or non-compliant, we do not have three valued logic here). It would be interesting to know more details about Unix validation. I guess the point here is that most systems that people think of as Unix are actually NOT called Unix (e.g. Linux, IRIX, AIX, Solaris), and so you have to be very careful in understanding what this validation means. I guess the issue here is IPR protection rather than propagation of an open standard. Precisely which commonly used Unix-like systems have been certified by the copyright holder in this manner? Can someone who does know the details enlighten here? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar @ 1996-04-07 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-07 0:00 ` Dan Pop 2 siblings, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828879781@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. No, it doesn't. Rather, it permits their addition only if no strictly conforming program can tell. Now, as it happens, Linux does do the right thing - if I define my own read(), I get *my* read any time I call read, so the implementation is conforming. If I got a conflict when I linked, the system would be violating ANSI. >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). Yes we do. There are conforming, strictly conforming, and unconforming programs. And there are many things an implementation could do which are partially compliant, I'm sure. (Although "partially compliant" is not defined by ANSI.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach ` (3 more replies) 0 siblings, 4 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said "Now, as it happens, Linux does do the right thing - if I define my own read(), I get *my* read any time I call read, so the implementation is conforming." Boy, this sure has wandered! THe original issue was the semantic behavior of read. Unlike other unices, in Linux, the bounds check for the read buffer is based on the requested count, rather than the actual count of data bytes read. It is hard to say either approach is right or wrong, but they are different enough to cause portability problems. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson ` (3 more replies) 1996-04-08 0:00 ` Lawrence Kirby ` (2 subsequent siblings) 3 siblings, 4 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828936837@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said >"Now, as it happens, Linux does do the right thing - if I define my own >read(), I get *my* read any time I call read, so the implementation is >conforming." >Boy, this sure has wandered! True enough. The above is the only ANSI related issue. >THe original issue was the semantic behavior >of read. Unlike other unices, in Linux, the bounds check for the read >buffer is based on the requested count, rather than the actual count >of data bytes read. It is hard to say either approach is right or >wrong, but they are different enough to cause portability problems. How? No offense meant, but any code which can be affected by this is flat out broken. POSIX-style read is to be given a pointer to at least nbytes of space, for the information read. Period. No correct code can ever be affected by the behavior of read when nbytes is larger than the size of the buffer. (For latecomers, the question is what happens if you *KNOW* that the file only has, say 100 bytes left, so call read with a 100-byte buffer, and nbytes==256.) I can't see how this is a "portability problem" any more than it's a portability problem that some systems will crash on printf("%s", (char *) 0); ... (SunOS won't, though.) Something which works only on some systems is not a portability problem *if there is no standard saying it works*. Likewise i = ++i; producing different results on different machines is not a "portability problem". If read() behaved dramatically differently with valid inputs, I would see it as a portability problem. (This applies to most of the C standard library, as well, of course. The behavior you're used to, such as "void main(void)" or "fflush(stdin)" not working, is not a portability problem, it's broken code.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach ` (2 more replies) 1996-04-08 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 3 replies; 177+ messages in thread From: Fergus Henderson @ 1996-04-08 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Robert Dewar <dewar@cs.nyu.edu> wrote: >>THe original issue was the semantic behavior >>of read. Unlike other unices, in Linux, the bounds check for the read >>buffer is based on the requested count, rather than the actual count >>of data bytes read. It is hard to say either approach is right or >>wrong, but they are different enough to cause portability problems. > >How? No offense meant, but any code which can be affected by this is flat >out broken. It is clear that (a) such code is broken and (b) the fact that it has undefined behaviour causes portability problems. What you said and what Robert Dewar said are not contradictory. >I can't see how this is a "portability problem" any more than it's a >portability problem that some systems will crash on > printf("%s", (char *) 0); >... (SunOS won't, though.) It is not *more* of a portability problem than `printf("%s", (char *) 0);', but the undefined behaviour of read() and printf() both cause portability problems. >Something which works only on some systems is >not a portability problem *if there is no standard saying it works*. Likewise > i = ++i; >producing different results on different machines is not a "portability >problem". Ha! Obviously you have never tried porting any serious C programs. >(This applies to most of the C standard library, as well, of course. The >behavior you're used to, such as "void main(void)" or "fflush(stdin)" not >working, is not a portability problem, it's broken code.) It's a portability problem AND it's broken code. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson ` (2 more replies) 1996-04-08 0:00 ` Robert Dewar 1996-04-10 0:00 ` Steve Summit 2 siblings, 3 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >It is clear that (a) such code is broken and (b) the fact that >it has undefined behaviour causes portability problems. >What you said and what Robert Dewar said are not contradictory. Yes, they are. There is no portability problem in the C language, or the behavior of read(). It is not a portability program for a mistake to behave randomly or differently on different machines. >>I can't see how this is a "portability problem" any more than it's a >>portability problem that some systems will crash on >> printf("%s", (char *) 0); >>... (SunOS won't, though.) >It is not *more* of a portability problem than `printf("%s", (char *) 0);', >but the undefined behaviour of read() and printf() both cause portability >problems. No, they define the boundaries of a language; things beyond that boundary are *supposed* to be undefined. Since no program in the C language ever runs into that behavior of a C implementation, it is not a portability problem. >>Something which works only on some systems is >>not a portability problem *if there is no standard saying it works*. Likewise >> i = ++i; >>producing different results on different machines is not a "portability >>problem". >Ha! Obviously you have never tried porting any serious C programs. Any program which does that is not a C program; it has left the bounds of defined behavior. Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed. >>(This applies to most of the C standard library, as well, of course. The >>behavior you're used to, such as "void main(void)" or "fflush(stdin)" not >>working, is not a portability problem, it's broken code.) >It's a portability problem AND it's broken code. It's a portability problem if you write that broken code; well, don't do that then. No point blaming the language for incompetent or foolish programmers. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 2 siblings, 1 reply; 177+ messages in thread From: Fergus Henderson @ 1996-04-09 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >>It is clear that (a) such code is broken and (b) the fact that >>it has undefined behaviour causes portability problems. >>What you said and what Robert Dewar said are not contradictory. > >Yes, they are. There is no portability problem in the C language, or >the behavior of read(). It is not a portability program for a mistake >to behave randomly or differently on different machines. No, it is definitely a portability problem if a mistake behaves differently on different machines. It is a portability problem, because almost every non-trivial program contains mistakes, and so if a mistake can behave differently on different machines, that means that almost every non-trivial program will behave differently on different machines. If behaving differently on different machines in ways not intended by the programmer isn't a portability problem, then I don't know what is! >>... the undefined behaviour of read() and printf() both cause portability >>problems. > >No, they define the boundaries of a language; things beyond that boundary >are *supposed* to be undefined. Since no program in the C language ever >runs into that behavior of a C implementation, it is not a portability >problem. ... Oh, nonsense. Such specious definitions You're trying to define the problem away, but the problem >>>Something which works only on some systems is >>>not a portability problem *if there is no standard saying it works*. >>>Likewise >>> i = ++i; >>>producing different results on different machines is not a "portability >>>problem". > >>Ha! Obviously you have never tried porting any serious C programs. > >Any program which does that is not a C program; it has left the bounds of >defined behavior. Oh, nonsense. Such specious definitions belong in an ivory tower, not in the real world. You're trying to define the problem away, but the problem is a very real problem which has very real costs. >Further, that behavior is a flat out bug; it is never correct, and the >portability problem lies in the program, not the language spec. The >program needs to be fixed. No, the portability problem is the different behaviour of the program, when run on different systems. It does not "lie in" the program -- it makes little sense to speak of behaviour "lying in" a program. The behaviour is not something that has a single cause -- rather, it has a multitude of causes, some direct, and some indirect. The problem is caused by the program AND by the implementation AND by the language spec. Of course, you can't really assign blame to any of these abstract entities; blame, if it is to be assigned, must be assigned to the people who wrote them. But you can't blame any of them too much. You can't really blame the language designers or language committee much; after all, they were just doing their best to specify the language in a way which allowed implementations some flexibility. You can't really blame the implementors, even though they may have known that defining things the way they did might lead to portability problems; after all, they were only following the spec! And you can't really blame the programmers too much for making the occasional mistake; after all, they are only human!! >No point blaming the language for incompetent or foolish programmers. Every programmer has done something incompetent or foolish at some time. Programming language design should take this, amoung other things, into account. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Fergus said "Every programmer has done something incompetent or foolish at some time." Except presumably Peter and Kazimir :-) :-) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829057929@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Fergus said > >"Every programmer has done something incompetent or foolish at some time." > >Except presumably Peter and Kazimir :-) :-) I don't see what this has to do with anything. I don't think that either of us has _purposely insisted_ on doing something incompetent or irrational in our programming. The debate is about doing something purposely and consciously, not about making mistakes. If I make a mistake in my call to read() or select(), that is not the same as an expression of belief that these calls work a certain way. It's just an error, plain and simple. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Tom Payne 1996-04-09 0:00 ` Robert Dewar 2 siblings, 2 replies; 177+ messages in thread From: Fergus Henderson @ 1996-04-09 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >>It is clear that (a) such code is broken and (b) the fact that >>it has undefined behaviour causes portability problems. >>What you said and what Robert Dewar said are not contradictory. > >Yes, they are. There is no portability problem in the C language, or >the behavior of read(). It is not a portability program for a mistake >to behave randomly or differently on different machines. No, it is definitely a portability problem if a mistake behaves differently on different machines. It is a portability problem, because almost every non-trivial program contains mistakes, and so if a mistake can behave differently on different machines, that means that almost every non-trivial program will behave differently on different machines. If behaving differently on different machines in ways not intended by the programmer isn't a portability problem, then I don't know what is! >>... the undefined behaviour of read() and printf() both cause portability >>problems. > >No, they define the boundaries of a language; things beyond that boundary >are *supposed* to be undefined. Since no program in the C language ever >runs into that behavior of a C implementation, it is not a portability >problem. ... >>Ha! Obviously you have never tried porting any serious C programs. > >Any program which does that is not a C program; it has left the bounds of >defined behavior. If you adopt that definition, then what I said -- that obviously you have never tried porting any serious C programs -- is still true, since no serious programs are written in 100% strictly conforming ANSI C. However, such specious definitions belong in an ivory tower, not in the real world. You're trying to define the problem away, but the problem is a very real problem which has very real costs. >Further, that behavior is a flat out bug; it is never correct, and the >portability problem lies in the program, not the language spec. The >program needs to be fixed. No, the portability problem is the different behaviour of the program, when run on different systems. It does not "lie in" the program -- it makes little sense to speak of behaviour "lying in" a program. The behaviour is not something that has a single cause -- rather, it has a multitude of causes, some direct, and some indirect. The problem is caused by the program AND by the implementation AND by the language spec. Of course, you can't really assign blame to any of these abstract entities; blame, if it is to be assigned, must be assigned to the people responsible. But you can't blame any of the people involved too much. You can't really blame the language designers or language committee much; after all, they were just doing their best to specify the language in a way which allowed implementations some flexibility. You can't really blame the implementors, even though they may have known that defining things the way they did might lead to portability problems; after all, they were only following the spec! And you can't really blame the programmers too much for making the occasional mistake; after all, they are only human!! >No point blaming the language for incompetent or foolish programmers. Every programmer has done something incompetent or foolish at some time. Programming language design should take this, amoung other things, into account. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Fergus Henderson 1996-04-10 0:00 ` Tom Payne 1 sibling, 1 reply; 177+ messages in thread From: Kenneth Mays @ 1996-04-09 0:00 UTC (permalink / raw) >Of course, you can't really assign blame to any of these abstract >entities; blame, if it is to be assigned, must be assigned to the >people responsible. But you can't blame any of the people involved too >much. You can't really blame the language designers or language >committee much; after all, they were just doing their best to specify >the language in a way which allowed implementations some flexibility. >You can't really blame the implementors, even though they may have >known that defining things the way they did might lead to portability >problems; after all, they were only following the spec! And you can't >really blame the programmers too much for making the occasional >mistake; after all, they are only human!! Interesting point. The C language still falls under Objective C, ANSI C, or some other variant - instead of just C. You have OWL and MFC libraries for MSDOS-based machines, and specialized libraries for SGI/Sun/Cray platforms. You can say its the language designers, and/or the language implementors, which is why I spoke of standardization of the base module of Ada95. Are we going to have Objective-Ada95, Ada95 V2.0, or whatever? You want to blame the programmers? Well I do believe that many programmers are young (or old) hackers or college graduates just starting out in the professional field. Hell, I just got through reading about DB/2 V3 when most businesses are still using V2.x!!! I could go into MicroFocus Visual COBOL issues but the point is that we are working with some of the new tools and those tools aren't always perfect. Technology is moving so fast that what you learn in a college class today might change before the week is over. There are so many patches, updates, fixes, and workarounds that either you are in the business (an MIS) of keeping up with the latest hacks or your company is left behind in the whirlwind. Programmers have a hard enough time trying to program besides doing multirole jobs in certain organizations. Blame it on the managers who push software engineers and programmers to release their software NOW, instead of next week (I don't blame everything on managers either). --> But when it comes to Ada95, the USAF and other agencies are depending a validated programming language that it can trust enough to put in those embedded systems - and get some good results from it. Many accidents are caused by bad programming habits or miscommunication between the programmer and system analyst/project manager - not so much the programming language. Even with C, there are many shortcuts and workarounds to do the same thing more efficiently and effectively - without garbage collection and with good error handling. Teach our programmers good programming habits and teach the managers how to understand good language design and analysis. I could say more but I'll leave it at that. Ken Mays, MIS, USAF http://www.wg53.eglin.af.mil (Webmaster) "The pursuit of excellence is a lethal habit - when you inject it into the minds of the incompetent." "That's mot a bug, that's a convertible!" ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kenneth Mays @ 1996-04-10 0:00 ` Fergus Henderson 0 siblings, 0 replies; 177+ messages in thread From: Fergus Henderson @ 1996-04-10 0:00 UTC (permalink / raw) KMays@msn.com (Kenneth Mays) writes: >You want to blame the programmers? [...] Blame it on >the managers who push software engineers and programmers to release >their software NOW, instead of next week Oh yes, I forgot to mention them. >(I don't blame everything on managers either). Yes, of course the managers are only fulfilling their role in a capitalist society - blame it on the politicians ;-) ;-) ;-) I think a better approach is to not worry about the search for scapegoats, but to instead do our best to search for ways to prevent such problems from arising in the future. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays @ 1996-04-10 0:00 ` Tom Payne 1 sibling, 0 replies; 177+ messages in thread From: Tom Payne @ 1996-04-10 0:00 UTC (permalink / raw) Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : seebs@solutions.solon.com (Peter Seebach) writes: [...] : >Further, that behavior is a flat out bug; it is never correct, and the : >portability problem lies in the program, not the language spec. The : >program needs to be fixed. : : No, the portability problem is the different behaviour of the program, : when run on different systems. It does not "lie in" the program -- it : makes little sense to speak of behaviour "lying in" a program. The : behaviour is not something that has a single cause -- rather, it has a : multitude of causes, some direct, and some indirect. The problem is : caused by the program AND by the implementation AND by the language spec. At the risk of mentioning the obvious, when the standard leaves a behavior "undefined", it increases the portability of the langauge (i.e., the ease of generating efficient object code on a large range of architectures) at the expense of portability of programs written in that language (i.e., same behavior under different implementations). "Undefined behavior" takes the implementors off the hook in many difficult situations and give them more control in others. Their life is made more comfortable at the expense of the programmer, who looses control and the ability to know what to expect in certain circumstances. Implementors are well represented in the C and C++ committees and the balance of power is reflected in the standards these groups have generated. Ada by contrast was developed under the auspices of the U.S. government's Department of Defense, a customer, not a vendor, of progrmming language implementations. I've not read the Ada standard but I'd expect the balance of power to be reflected in far less "undefined behavior." The problem shows up in real situations: In C++ AFAIK there is no efficient way for an exception at the hardware level to generate an exception (in the C++ sense) on the part of the running program -- the running must poll a volatile atomic variable to see if the exception has occurred. This obviously makes the langauge, as defined in the standard, unacceptable for use in the area of, say, embedded systems. Even in scientific progrmming, however, one would like to be able to throw an exception out of a matrix manipulation routine when the underlying hardware detects a floating point exception, and polling for such an occurrence would involve unacceptable overhead. Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Robert Dewar 2 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Peter Seebach said "Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed." Gosh, I was a little concerned that when I wrote my "portable programs are portable" note that it would be considered too obvious, but Peter certainly is confused, so perhaps it is worth restating. It is true of any language that a portable program is portable given: a portable program is one using only features of the language whose semantics is target independent. the implementations of the language on the machines involved are correct. But this is quite useless in the discussion of portability problems. It is indeed clear that Peter has not been involved in large porting efforts. His comments are reminiscent of an attitude that says "bugs in programs are not a problem - don't put bugs in your programs". In practice portability problems (i.e. problems in porting programs) stem from several possible sources: o Non-portable constructs introduced deliberately o Non-portable constructs introduced accidentally o Use of third party libraries etc, outside the language o Incomplete or inaccurate implementations In practice, porting large programs tends to run into problems of each variety. The language design is not exactly directly responsible in any of these areas, but it is also not completely independent of them either. Non-portable constructs introduced deliberately Some languages make it more necessary to do non-portabe programming than others, e.g. in C we cannot define integer types that have portable ranges, in Ada we can easily do so. Some languages allow extensions more freely. For example, most languages do not prohibit extensions in the standard -- the standard for COBOL for example (like most others) defines what the required feature set is and has nothing to say about programs outside the valid set. In the case of Ada, the standard requires rejection of any program NOT in the valid set. Non-portble constructs introduced accidentally This is more subjective certainly, but here too language plays a part. For example both C and Ada allow the type model to be broken, C easily with a cast, Ada only with a big syntactic stink about unchecked conversion. Another area where this occurs is when specs are vague, the discussion about read is a good example (although of course not directly relevant since read is not a language feature). An example in C is the exact semantics of X++ in a multi-threaded environment (there are obviously two possible semantics, normally the same, but not in a threaded environment). Use of third party libraries etc This can obviously be alleviated by including more such stuff in the language. Many people took the attitude that the original C language did not include I/O, but the ANSI standard clearly takes an opposite point of view and has incorporated many standard library routines. Similarly, Ada 95 differs from Ada 83 in the addition of a large standard library. Incomplete or inaccurate implementations Small, simple languages are likely to fair better here. FOr example, other things being equal, one would expect a C implementation to more easily and consistently be a full implementation of its spec than an Ada 95 or C++ implementation. Of course th "other things being equal" here is important. External factors such as the quality of validation suites, and the precision of the relevant standard, may well have a significant influence. But the bottom line here Peter is that we all know that in all languages it is possible for a very careful defensive programmer who knows the standard well, and who avoids likely trouble spots, can write portable code, especially if no system-dependent mucking is involved. But this has little to do with the practical issue of the world of portablity problems. I certainly agree that programmers who know the relevant standard are in better shape. It amazes me to find out how few C programmers have read the C standard (similar situations are true with Fortrn and COBOL). Ada interestingly is different, typical professional Ada programmers do have a copy of the Ada standard at hand, at least for reference purposes. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Steve Summit 2 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said ">Something which works only on some systems is >not a portability problem *if there is no standard saying it works*. Likewise > i = ++i; >producing different results on different machines is not a "portability >problem"." This is a perfect case of Peter saying: Language X ensures that all portable programs are portable, therefore there are no portability problems. This is of course vacuously true for all languages! By a "portability problem" most people mean that you take a program written in language X, and try to move it to machine Y from machine Z, and it does not work any more. Portability problems are most definitely caused by writing non-portable code. In fact in the absence of errors in the compiler of environment on machine Y or machine Z, this is the ONLY source of portability problems. However, it is definitely the case that languages vary in the ease with which people end up writing non-portable code deliberately or accidentally. For example, in C, we can't declare an integer variable without introducing a potential portability dpeendence on the range. Careful writing can get around this, or certainly minimize it, but it's often the source of porability problems. Typical Ada prograns do not suffer from this particular problem, because even a novice Ada programmer knows to avoid the use of predefined types in code that is intended to be portable. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1 sibling, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said > >">Something which works only on some systems is >>not a portability problem *if there is no standard saying it works*. Likewise >> i = ++i; >>producing different results on different machines is not a "portability >>problem"." > >This is a perfect case of Peter saying: Language X ensures that all >portable programs are portable, therefore there are no portability >problems. This is of course vacuously true for all languages! I'm not sure that he means this vacuous truth. I think that Peter would say that a program is portable if it is strictly compliant to a standard. In the case of C that means it avoids invoking implementation-defined and unspecified behavior, and certainly undefined behavior. >By a "portability problem" most people mean that you take a program >written in language X, and try to move it to machine Y from machine Z, >and it does not work any more. Yes, according to your empirical/pragmatic conception of portabilitity. >Portability problems are most definitely caused by writing non-portable >code. In fact in the absence of errors in the compiler of environment >on machine Y or machine Z, this is the ONLY source of portability >problems. > >However, it is definitely the case that languages vary in the ease with >which people end up writing non-portable code deliberately or >accidentally. > >For example, in C, we can't declare an integer variable without >introducing a potential portability dpeendence on the range. Careful It's not that bad because there are those ``minimum maximums'' defined by the ANSI standard for <limits.h>. An int is at least -32767 to 32767, a long is at least -2^31+1 to 2^31-1, and an unsigned long at least 2^32-1. These ranges are guaranteed, and can be assumed by any portable program. From Peter Seebach's FAQ: Herewith, some infrequently-asked questions and their answers: Section 1. Declarations and Initializations 1.1: How do you decide which integer type to use? A: Use ``short'' when you need to avoid values over 32,767, ``int'' when you want to store integers, ``long'' for long numbers (more than 6 digits), and ``float'' for numbers over 4 billion. 1.2: What should the 64-bit type on new, 64-bit machines be? A: int. 1.3: If I write the code int i, j; can I assume that (&i + 1) == &j? A: Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. Pretty easy, if you ask me! -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir quoted "Peter's FAQ" as saying: 1.3: If I write the code int i, j; can I assume that (&i + 1) == &j? A: Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. I think a smiley is missing here. This is a nice joke, but one can only hope that no one thinks that the EBCDIC comment is technically relevant. Incidentally, the answer that int should always be 64 bits on a 64-bit machine is far too facile. This is a very tricky question, which has been debated endlessly and no satisfactory solution found. There are very delicate tradeoffs to be made between efficiency, functionality, and portability here, and the final outcome is far from clear. Lots of C programs assume that long is 32 bits. Yes of course they are broken, yes of course this was a naughty assumption (of course ther is no way in C to get a guaranteed 32-bit integer type, so it is not surprising that C code is often broken in this manner). This means that making int (and hence long?) 64 bits caues serious porability problems. Yes, of course I talk about portability problems in a pragmatic sense, it is the only useful sense in whch to discuss them, since the discussion in purely language terms is vacuuous. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 177+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <dewar.829050467@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: > Kazimir quoted "Peter's FAQ" as saying: > > 1.3: If I write the code > > int i, j; > > can I assume that (&i + 1) == &j? > > A: Only sometimes. It's not portable, because in EBCDIC, i and j are > not adjacent. > > > I think a smiley is missing here. This is a nice joke, but one can only > hope that no one thinks that the EBCDIC comment is technically relevant. Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was assuming that everyone here would have lurked at least a week and a half in the newsgroup and thus would have read `Peter's FAQ' when it was posted on April 1st, with proper smileys, warnings, caveats etc. Of course, this isn't just going to comp.lang.c. But perhaps someone with a reasonable knowledge of C would have spotted the toungue-in-cheek ness? .splitbung -- * TQ 1.0 * The 'Just So Quotes'. My goal is a simple one: To live forever -- or die trying. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley @ 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 0 siblings, 2 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-11 0:00 UTC (permalink / raw) In article <829194287snz@tsys.demon.co.uk>, Tom Wheeley <tomw@tsys.demon.co.uk> wrote: >Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was >assuming that everyone here would have lurked at least a week and a half in >the newsgroup and thus would have read `Peter's FAQ' when it was posted on >April 1st, with proper smileys, warnings, caveats etc. Smileys, warnings, caveats or any other April Fool's designations drastically reduce the impact of the thing. By the way, when it was posted by Peter, it carried no such markings either, other than the date. When I started into it, I was caught by surprise. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 1 sibling, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkrijINN6oi@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >Smileys, warnings, caveats or any other April Fool's designations drastically >reduce the impact of the thing. By the way, when it was posted by Peter, it >carried no such markings either, other than the date. When I started into it, >I was caught by surprise. Heh! Well, I've been considering breaking down and producing an annotated version. I get far too many "corrections", most of which are actually less accurate than the original answers. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach @ 1996-04-13 0:00 ` Tom Wheeley 1 sibling, 0 replies; 177+ messages in thread From: Tom Wheeley @ 1996-04-13 0:00 UTC (permalink / raw) In article <4kkrijINN6oi@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca "Kazimir Kylheku" writes: > In article <829194287snz@tsys.demon.co.uk>, > Tom Wheeley <tomw@tsys.demon.co.uk> wrote: > >Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was > >assuming that everyone here would have lurked at least a week and a half in > >the newsgroup and thus would have read `Peter's FAQ' when it was posted on > >April 1st, with proper smileys, warnings, caveats etc. > > Smileys, warnings, caveats or any other April Fool's designations drastically > reduce the impact of the thing. By the way, when it was posted by Peter, it > carried no such markings either, other than the date. When I started into it, > I was caught by surprise. Hmm, it seemes you are right, however, there is always: 18.27: Is this FAQ for real? ..splitbung, who had heard of the c-iaq by reputation, and so was expecting it -- * TQ 1.0 * The 'Just So Quotes'. "Laundry increases exponentially in the number of children." -- Miriam Robbins ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1 sibling, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >By a "portability problem" most people mean that you take a program >written in language X, and try to move it to machine Y from machine Z, >and it does not work any more. Right. No behavior of "i=++i", or of someone twiddling the internals of a stdio FILE, can be unportable, because no program doing those is written in C. They are portability problems of the language "incorrect C", which is beyond the intended scope of comp.lang.c. :) Really; any time you are writing things not specified in any spec, you have left the realm of what that spec guarantees, and nothing that happens to you is a portability problem with that spec. It may be a weakness problem with that spec; C's spec is certainly too weak in some areas. But it's possible to implement it on nearly anything, which was the goal. >Portability problems are most definitely caused by writing non-portable >code. In fact in the absence of errors in the compiler of environment >on machine Y or machine Z, this is the ONLY source of portability >problems. This, we agree on, mostly... >However, it is definitely the case that languages vary in the ease with >which people end up writing non-portable code deliberately or >accidentally. Also very true. I believe it is basically impossible to meaningfully write portable machine code. (Exceptions exist; there was a program in the IOCCC which worked on a VAX *or* a PDP.) >For example, in C, we can't declare an integer variable without >introducing a potential portability dpeendence on the range. Careful >writing can get around this, or certainly minimize it, but it's often >the source of porability problems. Typical Ada prograns do not suffer >from this particular problem, because even a novice Ada programmer >knows to avoid the use of predefined types in code that is intended >to be portable. This is a known limitation of C, and may be addressed by C9X. I hope it is; it's one of the few areas where I feel the language is fundementally incapable of doing what I want it to do. Luckily, it doesn't affect most of what I'm working on these days. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Steve Summit 1996-04-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 177+ messages in thread From: Steve Summit @ 1996-04-10 0:00 UTC (permalink / raw) [followups trimmed, and should probably be trimmed further] In article <dewar.828987544@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > Lots of code is portable and broken, lots of code is (deliberately) > non-portable and definitely not broken. Lots of code is carefully > written to be portable, but runs into bugs in supposedly conforming > implementations. Lots of code uses features that are useful, but for > which no standard exists, and hence may run into portability problems. All true. > Equating portability with non-brokenness in general is naive. Even in > an environment with a definite standard, writing portable code requires > a lot more than just adhering to the letter of the standard! Also true. There's a lot of naivete in some of the knee-jerk reactions about portability and conformance which tend to get made here. (I'm probably guilty of this myself.) Perhaps the essence of the debate is getting lost in the shouting. An example was brought up which, I gather, boils down to char buf[100]; /* exactly 68 characters are known to be available on fd */ read(fd, buf, 1000); It wasn't clear whether this was being presented as a real-world example of a portability problem, or as an example of code that someone thinks should be written, should be portable in practice, and should work. (I sincerely hope it's the former, and Robert Dewar has assured me that he, for one, is not defending it.) Asserting that non-strictly-conforming programs are not C programs, or that Good programs are Portable, or that Unix is standard, is naive. But deliberately pushing the boundaries of what is conforming, or even worse, arguing that code which is obviously dubious but which "obviously has to work" therefore *must* work, is variously foolish, misguided, culpable, criminal, and/or suicidal. In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes: > seebs@solutions.solon.com (Peter Seebach) writes: >> ... The [undefined] behavior you're used to... >> is not a portability problem, it's broken code.) > > It's a portability problem AND it's broken code. What Fergus says is also true. Where the distinction arises is in one's reaction once the problem is discovered. Some people (I'd like to say most people) are aghast when they discover code as broken as char buf[100]; read(fd, buf, 1000); and hasten to fix it. It seems that others, though, engage in lengthy arguments about what some standard ought to say that the code in question ought to do, as if the code in question ought to do anything useful. Let's not lose sight of the end goal here, which is neither to spend the rest of our days arguing about standards nor fixing bugs, but rather to write useful programs that work. Yes, it's hard to write a correct program. Yes, it's even harder to write an airtight standard. Yes, compromises between the letter of a standard and the peculiarities of existing practice are often required when writing compilers. But chortling with glee as you discover that you can call read(fd, buf, 1000) even though buf is only 100 characters long, because you've oh-so-cleverly noticed and oh-so-carefully proved that fd can contain no more than 68 remaining characters, is not the sort of behavior that's likely to lead to long-term stability of one's programs or adulation from one's successors. Nor, evidently, does coming back with "But where does which standard say it's illegal?" immediately endear you to some of your fellow supplicants on this mortal coil here. (Yes, the 68-character-buffer example is an extreme one, and no one in this thread has been "chortling with glee." But it's reminiscent of the kind of arguments that come up all the time.) The wise thing to do, it seems to me, is to fix the bugs and overt portability problems, try to figure out better ways of avoiding them in the future, and move on. If the documentation needs to be rewritten to make it clear that the N in "read() may return -1, with errno set to EFAULT, if buf does not point to at least N contiguous bytes of writable storage" is the N that is read's third argument, then so be it. (If the documentation doesn't even mention EFAULT or buf's allocation, that may be a bigger problem.) Is there really anything else that needs discussing here? (Actually, of course, none of this needs discussing "here," where "here" is the set of newsgroups this thread is currently crossposted to. It probably belongs in comp.std.unix, or comp.programming, or comp.software-eng.) Steve Summit scs@eskimo.com ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Steve Summit @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Steve said/asked >Perhaps the essence of the debate is getting lost in the shouting. >An example was brought up which, I gather, boils down to > > char buf[100]; > /* exactly 68 characters are known to be available on fd */ > read(fd, buf, 1000); > >It wasn't clear whether this was being presented as a real-world >example of a portability problem, or as an example of code that >someone thinks should be written, should be portable in practice, >and should work. (I sincerely hope it's the former, and Robert >Dewar has assured me that he, for one, is not defending it.) Of course it is being brought up as an example of a portability problem. As for (a) should be written (b) should be portable in practice (c) should work I would say, historically, (b) and (c), but not necessarily (a). If the spec of the POSIX read were defined to say "the buffer must be at least as long as the data that is read", then certainly (b) and (c) would be true. As for (a), note that of course *no one* would explicitly write the dubious code, it occurs in the context of a loop, something like while (p < endbuf) {read(fd, p, 8192); p+=8192;) where the precondition is that the data read from fd is known not to go "past" endbuf. Of course it is possible to modify this code so that the last read does not have an excessive count, but the resulting code is a little more complex. The issue is not whether this code is defensible or not. Clearly this was in fact a significant bug, since the code broke on Linux, and this was intended to be portable, so it was wrong, caused trouble, and had to be fixed. In that sense it was certainly wrong! However, given the vague definition of read, it is easy to see how the coder here in fact assumed that (b) and (c) were true, and hence the bug arose. If the spec of read had said: "the buffer must be at least the length given by the third parameter, even if the actual data is smaller", then of course the error would not have been made in the first place. And that, all along has been my point. Careful specification of interfaces, and accurate knowledge of these specifications, can definitely improve portability. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku ` (2 more replies) 1996-04-09 0:00 ` Steve Tynor 1996-04-12 0:00 ` Gareth Rees 3 siblings, 3 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said "How? No offense meant, but any code which can be affected by this is flat out broken. POSIX-style read is to be given a pointer to at least nbytes of space, for the information read. Period." That's really confusing, the code in question DID give a buffer large enough to hold nbytes of data, where nbytes is the number of bytes for "the information read". Maybe I don't understand, but reading the above sentence, it sounds like you would be surprised by the Linux behavior. Here is the exact case. We declare a buffer of 100 bytes. We read a 1000 bytes from a file whose total length is 68 bytes. On all systems that we had experience with other than Linux, this worked fine, the first 68 bytes of the buffer is filled, and the remaining 32 bytes is unused. I am not claiming this is "correct" code in some abstract sense. I certainly can't tell that it is wrong from the definitions I have of the read function. What I am claiming is that this worked on all systems we tried it on, and then failed on Linux. I am not saying Linux is wrong here, just that its behavior was surprising! The code in question made 100% sure that the data read would never exceed the buffer size, and I would have been hard pressed to determine that the code was incorrect. I am not sure that POSIX is relevant here, almost none of the systems on which we ran claimed POSIX compliance. Peter, can you post the POSIX wording on read, I don't have it at hand. Does it in fact make it clear that the Linux behavior is correct and that the program was wrong. Let's suppose that the POSIX standard does in fact make it clear that the Linux behavior is correct. I still think the check is unwise (note that the check is not against the actual size of the buffer given, this is of course impossible in C, it is against the end of the address range of the data area). It's a good example of the kind of principle I mentioned before. Since almost all systems allow the program I described above to work correctly, and it is manifestly safe programming evenif the check is not present, I think it would be a better choice for Linux not to do this extra check. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` John Marshall 2 siblings, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.829011320@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said > >"How? No offense meant, but any code which can be affected by this is flat >out broken. POSIX-style read is to be given a pointer to at least nbytes >of space, for the information read. Period." > >That's really confusing, the code in question DID give a buffer large >enough to hold nbytes of data, where nbytes is the number of bytes >for "the information read". Maybe I don't understand, but reading the >above sentence, it sounds like you would be surprised by the Linux >behavior. > >Here is the exact case. We declare a buffer of 100 bytes. We read a >1000 bytes from a file whose total length is 68 bytes. On all systems >that we had experience with other than Linux, this worked fine, the >first 68 bytes of the buffer is filled, and the remaining 32 bytes >is unused. This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and until now I have been completely oblivious to this difference between Linux and other systems. Unfortunately, I could not find anything in POSIX.1 that would explicitly disallow this. The document is not very assertive in defining undefined behavior. I'm going to check it once again in case I missed something. I checked the manual pages for read() on several systems. Linux documents that EFAULT results if the buffer pointed at by buf is outside of the address space of the process. On other systems, it is claimed that EFAULT results if the buf pointer is directed outside of the address space. >I am not claiming this is "correct" code in some abstract sense. I >certainly can't tell that it is wrong from the definitions I have >of the read function. What I am claiming is that this worked on >all systems we tried it on, and then failed on Linux. I am not saying >Linux is wrong here, just that its behavior was surprising! It's not surprising: you lied to the read() function. But you are right, you can't tell this from the definition in POSIX.1 or from typical manual pages. There are certain unwritten rules, though! >The code in question made 100% sure that the data read would never >exceed the buffer size, and I would have been hard pressed to >determine that the code was incorrect. Really? What if another process appended data to the file before you got to the end? A simple script running as the same user ID as the program would always have the right permissions to do this, provided the file in question is not a temporary file that was unlinked before being written. What prevented the code from advertizing the true buffer size of 100? Can we see this code, along with some of its context? In any case, it doesn't sound like a case of ``defensive programming''. >I am not sure that POSIX is relevant here, almost none of the systems on >which we ran claimed POSIX compliance. Peter, can you post the POSIX >wording on read, I don't have it at hand. Does it in fact make it >clear that the Linux behavior is correct and that the program was >wrong. The POSIX.1 wording on read() doesn't get into anything that is remotely helpful in this discussion at all. In fact, the whole document is only an interface specifiction that basically tells you how these functions are called and what are their semantics, and minimal error conditions. >Let's suppose that the POSIX standard does in fact make it clear that >the Linux behavior is correct. I still think the check is unwise I checked the POSIX.1 document and it does not make it clear. The importance of the EFAULT checks is downplayed, and I could not find a definite statement in the document that passing illegal arguments even leads to undefined behavior. There is a gaping lack of a comprehensive list of what constitutes non-portable or illegal use of the functions, as far as I could tell. >(note that the check is not against the actual size of the buffer >given, this is of course impossible in C, it is against the end >of the address range of the data area). It's a good example of the >kind of principle I mentioned before. Since almost all systems allow >the program I described above to work correctly, and it is manifestly >safe programming evenif the check is not present, I think it would >be a better choice for Linux not to do this extra check. And allow kernel code to potentially make an illegal reference to a not present page? I'd rather not have it that way just to fix the extremely rare buggy program. Perhaps checking the bounds just for the actual data transferred might be better. But this would complicate the kernel code. It's easy to check the buffer first, immediately upon entry into the read() system call, when it is not known how many bytes will be read from the given file or device. From there, control can pass to any of a number of subsystems via a function pointer in the f_op structure of the file node. Since the check is done at the entry point, the individual read() functions of various filesystem modules and device drivers can confidently use the entire buffer without having to do their own check after determining the actual transfer size. IMHO, requiring the individual read functions to do their own checking would result in unnecessary complication, when it it so easy and obvious to do a comprehensive check in the central sys_read() dispatcher! When working on a new device driver, I wouldn't want to mess around with details that should be taken care for me. If you want an example of behavior that is unequivocally ``different'', look no further than the Linux select() call. Unlike what happens on other UNIXes, the Linux select() system call modifies the timeval structure. Code that depends on the structure not being modified will break. This tripped me up, and caused some fairly prominent programs to behave differently (including some versions of the Mosaic web browser, which used select() as a delay mechanism. The little globe picture would spin like crazy, since Mosaic assumed that the delay values were preserved for multiple invocations of select rather than decremented down to nothing!) -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Lawrence Kirby 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir said: >This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a >pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and >until now I have been completely oblivious to this difference between Linux >and other systems. The spec of an interface does not depend on what "wouldn't even occur" to Kazimir, it must be independently defined. >Unfortunately, I could not find anything in POSIX.1 that would explicitly >disallow this. The document is not very assertive in defining undefined >behavior. I'm going to check it once again in case I missed something. This is not a matter of defining undefined, it is a matter of defining the requirement on the length of the read buffer, and it is truly amazing to me that none of the references at hand, not even the POSIX document, specifies this. >It's not surprising: you lied to the read() function. But you are right, you >can't tell this from the definition in POSIX.1 or from typical manual pages. Sorry, this is wrong, I lied to the *implemention* of the function as it occurred in Linux. Now it is true that the spec of the function is different in Linux than in other systems (you quoted the manual pages that showed this clearly). So of course we have a portability problem here. Read is different in different systems, not only at the implementation level, but at the spec level. The program in question was correct with respect to the spec on "other systems": >I checked the manual pages for read() on several systems. Linux documents >that results if the buffer pointed at by buf is outside of the address space >of the process. On other systems, it is claimed that EFAULT results if >the buf pointer is directed outside of the address space. Kazimir, perhaps you don't understand the whole idea of specs, but that quote means that code that makes sure that the pointer is directed inside the address space is OK if the buffer is not overrun! >There are certain unwritten rules, though! That's the totally unacceptable viewpoint that is at the center of the concerns in this thread (the details of read are uninteresting). The trouble is of course that Kazimir's unwritten rules are clearly different from other unwritten rules. I think one of the most essential things to understand in programming is the importance of abstracting specifications from implementation. Comments like the above (unwritten rules) one show that there is a long way to go! >What prevented the code from advertizing the true buffer size of 100? >In any case, it doesn't sound like a case of ``defensive programming''. Whoever said it was? With respect to the discussion of seperate processes adding to the file etc, this is irrelevant to the discussion of the spec difference. For the program in question, you still get a different behavior on the two systems: On Linux, you always get an exception On "other systems", you get defined behavior, and no exception, unless this unlikely external event lengthens the file, in which case you get undefined behavior. These are quite different semantics, and it is different semantics that result in one kind of portability problem. The observation about appending to the file is relevant in recommending that the count reflect the actual count expected to be read, and of course this was LONG ago corrected, within hours of finding the Linux behavior, so I can't show you the incorrect code. But the fact remains that we have a portability problem which SHOULD be cleared up by POSIX (or perhaps by SPEC1170), but apparently is not mentioned by POSIX< and I am willing to bet that SPEC1170 is similiarly vague. The standard of precision in defining specs of routines at this level is generally appalling. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Lawrence Kirby 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829051685@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: > Sorry, this is wrong, I lied to the *implemention* of the function as > it occurred in Linux. Now it is true that the spec of the function is > different in Linux than in other systems (you quoted the manual pages > that showed this clearly). So of course we have a portability problem > here. Read is different in different systems, not only at the > implementation level, but at the spec level. The program in question > was correct with respect to the spec on "other systems": What makes the code non-portable is that it depends on a behaviour of read() that is not guaranteed by the relevant standard (POSIX in this case). That this may be down to vagueness in the standard doesn't change the fact. In some cases there may be an argument based on clear intent but I don't think this is one of them. Linux just happened to be the first system that showed up the inherent non-portability of the code. Correctness considerations aside, there is never a good reason to pass a value in the 3rd argument to read() that is greater than the available buffer size. IMHO code that does this is highly suspect whether or not you argue that it is legal. I wish more systems were like Linux and trapped this, maybe they will in the future. >>I checked the manual pages for read() on several systems. Linux documents >>that results if the buffer pointed at by buf is outside of the address space >>of the process. On other systems, it is claimed that EFAULT results if >>the buf pointer is directed outside of the address space. > > Kazimir, perhaps you don't understand the whole idea of specs, but that > quote means that code that makes sure that the pointer is directed inside > the address space is OK if the buffer is not overrun! Right, it appears that the spec. for 'other systems' is incorrect (or at least unlikely to match what happens in practice). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Lawrence Kirby @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` David Emery 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Lawrence says "Correctness considerations aside, there is never a good reason to pass a value in the 3rd argument to read() that is greater than the available buffer size. IMHO code that does this is highly suspect whether or not you argue that it is legal. I wish more systems were like Linux and trapped this, maybe they will in the future." Highly imprecise thinking here I fear. There is no practical way for any implementation to do the check you mention (this = value in 3rd argument that is greater than the available buffer size). This is C remember! We are passing a pointer, the caller routine has no way of knowing the buffer length, and in general unless you keep structured pointers which now the bounds of the object they reference (something no real C compiler does), there is no way to make the check. Linux simply checks that the end of the buffer is in the memory area, which is not the check you would like to see. That's what I was talking about when I noted that this kind of uncertainty would not occur in a language with a reasonably complete type model. What exactly *is* the wording of the POSIX standard here (Lawrence, you must have it at hand, please quote it exactly). The interesting thing is to determine whether this definition says enough to make *any* use of read defined without appealing to "unwritten rules". I would guess not! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` David Emery 1 sibling, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829096975@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Linux simply checks that the end of the buffer is in the memory area, >which is not the check you would like to see. That's what I was talking >about when I noted that this kind of uncertainty would not occur in >a language with a reasonably complete type model. Precisely. The kernel defends itself against making a faulty dereference that would trigger an exception, but will happily corrupt your valid data, unless stated buffer range sticks over into an unmapped page. >What exactly *is* the wording of the POSIX standard here (Lawrence, you >must have it at hand, please quote it exactly). The interesting thing >is to determine whether this definition says enough to make *any* use >of read defined without appealing to "unwritten rules". I would guess >not! Unwritten rules, or paranoia. Take your pick! (Door #2 for me, please) The standard is basically very good at telling you what the functions do. BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual from 1984. ;) heh -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Kazimir said "BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual from 1984. ;) heh" Actually, the Ada spec for the corresponding function is absolutely clear. This is because the strong typing of Ada leaves no doubt as to the semantics of exceeding the buffer size, and the called routine knows the length of the buffer. One problem that I notice a lot of people have is in reading precise standards. A lot of people actually prefer vague descriptions with a few examples. Again the issue is one of training. Recently in my undergraduate class a student posted a note to the course list claiming that all books are useless and unreadabe, and that the only way to learn to program is to see examples. Sigh! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829136049@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir said > >"BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual >from 1984. ;) heh" > >Actually, the Ada spec for the corresponding function is absolutely clear. >This is because the strong typing of Ada leaves no doubt as to the >semantics of exceeding the buffer size, and the called routine knows >the length of the buffer. It does! I was just kidding to be a pest! :) Do you think that the extra detail in the corresponding Ada function has any influence on how the ambiguities in the C function ought to be resolved? -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` David Emery 1 sibling, 0 replies; 177+ messages in thread From: David Emery @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829096975@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote: ... > What exactly *is* the wording of the POSIX standard here (Lawrence, you > must have it at hand, please quote it exactly). The interesting thing > is to determine whether this definition says enough to make *any* use > of read defined without appealing to "unwritten rules". I would guess > not! I checked today. POSIX.1 (1995 version) is completely silent about what happens when the count > the length of buf. I wish I brought my standard home, so I could quote it, but it says something like "read transfers count characters into the buffer pointed to by buf." The standard is completely silent about the characteristics of buf, and one could do some 'formal standards reasoning' that says that *any* program that depends on the relationship between buf and count is non-compliant, in that it is depending on unspecified behavior. One would have expected for the standard to say something like "the buffer pointed to by buf, which is expected to be capable of holding at least count bytes..." Oftentimes, POSIX is deliberately silent in some areas, particularly error handling, because there was no consensus on behavior. Thus any behavior is "undefined", and any implementation is 'conforming', regardless of what it does. Personally, I think it's very poor standardization practice to be silent in such cases, I'd much prefer the standard to explicitly specify such behaviors as 'undefined', to warn the user. In this case, I would have preferred for POSIX.1 to say "If the size of the storage area pointed to by buf exceeds the value of count, the results of any transfer into buf is unspecified." Additionally, there is no explicit error code identified for "too much stuff in the buffer". But POSIX.1 permits implementation extensions in such a circumstance, so the Linux implementation is perfectly conforming, as are implementations that blindly write into some other address space and implementations that detect the fault and immediately send email to CJIII and his lawyer :-) (Even in Ada, writing past the end of an array using unchecked programming can result in any sort of behavior, including trashing the boot track of the system disk....) dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Lawrence Kirby @ 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829051685@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir said: > >>This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a >>pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and >>until now I have been completely oblivious to this difference between Linux >>and other systems. > > The spec of an interface does not depend on what "wouldn't even occur" > to Kazimir, it must be independently defined. I totally agree. But in the absence of the definition, we have to stick with the safer thing. >>Unfortunately, I could not find anything in POSIX.1 that would explicitly >>disallow this. The document is not very assertive in defining undefined >>behavior. I'm going to check it once again in case I missed something. > > This is not a matter of defining undefined, it is a matter of defining > the requirement on the length of the read buffer, and it is truly > amazing to me that none of the references at hand, not even the POSIX > document, specifies this. I might come up with something up if I read the damn thing character by character, cover to cover. But I did spend a fair bit of time chasing around the document, in vain. >>It's not surprising: you lied to the read() function. But you are right, you >>can't tell this from the definition in POSIX.1 or from typical manual pages. > > Sorry, this is wrong, I lied to the *implemention* of the function as > it occurred in Linux. Now it is true that the spec of the function is > different in Linux than in other systems (you quoted the manual pages > that showed this clearly). So of course we have a portability problem > here. Read is different in different systems, not only at the > implementation level, but at the spec level. The program in question > was correct with respect to the spec on "other systems": > >>I checked the manual pages for read() on several systems. Linux documents >>that results if the buffer pointed at by buf is outside of the address space >>of the process. On other systems, it is claimed that EFAULT results if >>the buf pointer is directed outside of the address space. > > Kazimir, perhaps you don't understand the whole idea of specs, but that > quote means that code that makes sure that the pointer is directed inside > the address space is OK if the buffer is not overrun! Right. The distinction is quite clear. The Linux doc talks about the whole buffer object, whereas the SunOS and HP-UX man pages talk about the buffer pointer. >>There are certain unwritten rules, though! > > That's the totally unacceptable viewpoint that is at the center of > the concerns in this thread (the details of read are uninteresting). > The trouble is of course that Kazimir's unwritten rules are clearly > different from other unwritten rules. I believe that my unwritten rules agree with what other UNIX/POSIX programmers also believe about the read() function, the same way that those Fortran 66 programmers held a consensus about the reversed DO loop or large array passing. > I think one of the most essential things to understand in programming > is the importance of abstracting specifications from implementation. > Comments like the above (unwritten rules) one show that there is a > long way to go! My reasoning was not based on any implementation. I actually got the idea of these unwritten rules from your posting about language implementations which give a meaning to certain behaviors that are not standard simply to reflect practice among programmers (like the Fortran 66 unwritten 'at least once' semantics for a reversed DO loop that you mentioned). In this case, the unwritten rule is not that you may misrepresent the buffer size, but rather the opposite. Conduct a survey of UNIX programmers, and see. :) This empirical notion about unwritten rules is thanks to you, not me! I abstract to the safer alternative regardless of what anyone thinks. Of course, this heuristic doesn't work all the time. It failed in the case of select(). How was I to guess that the function will modify the timeval structure, when the program worked properly on two other systems? There is clearly another ``unwritten rule'' about the behavior of select(), but in this case I unconsciously believed in it. After running into the problem, I no longer believe in the ``unwritten rule'' but in the safest rule, and no longer count on the contents of the timeval structure being preserved after a select() call, regardless of the implementation. In the case of read(), my intuition has always been to specify the actual buffer size. It just so happens that in this case the weaker assumption is in agreement with the common belief, whereas in the case of select() the stronger assumption is the common belief. The difference between safest assumptions and unwritten rules is that the latter are subjective, because they are determined by the concensus of community of programmers, whereas the former are not subjective because they are based on rational reasoning. Are you familiar with ``Pascal's Wager''? It is a way to decide between alternate hypotheses. You draw a table like this: call read() with exaggerate the buffer correct buffer size the buffer size to read() lying about You are OK You are OK buffer is OK lying about You are OK You could be screwed buffer is *NOT* OK. I'm not about to pick the lower right hand corner, just because I can interpret the vague spec in a way that could justify a belief in the corresponding hypothesis. Pascal used this method of inference to justify a belief in God, incidentally, hence the name. :) It has nothing to do with my belief about what the implementations are like, or what the unwritten rules are. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` John Marshall 2 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829011320@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said >"How? No offense meant, but any code which can be affected by this is flat >out broken. POSIX-style read is to be given a pointer to at least nbytes >of space, for the information read. Period." >That's really confusing, the code in question DID give a buffer large >enough to hold nbytes of data, where nbytes is the number of bytes >for "the information read". Maybe I don't understand, but reading the >above sentence, it sounds like you would be surprised by the Linux >behavior. If you don't provide enough space for the number of bytes you request, you are lying to the system. I cannot imagine a reason to do this, though I'm curious. >Here is the exact case. We declare a buffer of 100 bytes. We read a >1000 bytes from a file whose total length is 68 bytes. On all systems >that we had experience with other than Linux, this worked fine, the >first 68 bytes of the buffer is filled, and the remaining 32 bytes >is unused. Why are you reading 1000 bytes if you *know* there aren't that many? Also, how do you propose to *prove* that, between your last check, and your read, no one has added to the file? There's no sane strategy here. But mostly, I can't imagine any reason to do this; if you know there are no more than N bytes of data that you want, what possible reason is there to read more than N? >I am not claiming this is "correct" code in some abstract sense. I >certainly can't tell that it is wrong from the definitions I have >of the read function. What I am claiming is that this worked on >all systems we tried it on, and then failed on Linux. I am not saying >Linux is wrong here, just that its behavior was surprising! I'm not surprised at all; I'd not be surprised by any syscall doing bounds checking on arguments. What's wrong is that you're lying; you are saying "here's a buffer to read 1000 bytes into, it's large enough" and it's not large enough for 1000 bytes. >The code in question made 100% sure that the data read would never >exceed the buffer size, and I would have been hard pressed to >determine that the code was incorrect. I'd love to know how you're sure of this in a multitasking environment. >I am not sure that POSIX is relevant here, almost none of the systems on >which we ran claimed POSIX compliance. Peter, can you post the POSIX >wording on read, I don't have it at hand. Does it in fact make it >clear that the Linux behavior is correct and that the program was >wrong. I don't have it at hand either; I can say that the basic statment made is that it reads at most nbytes bytes from file into the buffer. I don't think the issue is explicitly addressed, because no one had ever tried it. >Let's suppose that the POSIX standard does in fact make it clear that >the Linux behavior is correct. I still think the check is unwise >(note that the check is not against the actual size of the buffer >given, this is of course impossible in C, it is against the end >of the address range of the data area). It's a good example of the >kind of principle I mentioned before. Since almost all systems allow >the program I described above to work correctly, and it is manifestly >safe programming evenif the check is not present, I think it would >be a better choice for Linux not to do this extra check. It's certainly *possible* for a C implementation to do full and rigorous bounds checking, even if it's rare. I disagree; I believe implementations must be *especially* zealous about catching and crashing common mistakes. I do not believe conceptually invalid code should be allowed to run, if there's any way to test for it. I have only once in my life seen a compiler cause i = ++i; to do anything but increment i. This doesn't mean that compiler was wrong, in *any* way. The code is devoid of meaning, and it's merely bad luck that so many implementations don't catch it. I don't think I agree with the claim that it's manifestly safe. An unexpected hard error could cause the disk to spew more data than you just proved it had, and you should *NEVER* give a syscall license to write past the space you want it to work with. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach @ 1996-04-10 0:00 ` John Marshall 1996-04-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 177+ messages in thread From: John Marshall @ 1996-04-10 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: > Peter said >> "How? No offense meant, but any code which can be affected by this is flat >> out broken. POSIX-style read is to be given a pointer to at least nbytes >> of space, for the information read. Period." > > That's really confusing, the code in question DID give a buffer large > enough to hold nbytes of data, where nbytes is the number of bytes > for "the information read". Maybe I don't understand, but reading the > above sentence, it sounds like you would be surprised by the Linux > behavior. I think your confusion comes from misunderstanding what Peter is using "nbytes" to mean: he is referring to the parameter in the read() call. > Here is the exact case. We declare a buffer of 100 bytes. We read a > 1000 bytes from a file whose total length is 68 bytes. Can I try to demonstrate why this is unreasonable? I don't have any definitive documentation here, but I believe the wording of the *contract* between application writer and library writer is something like: int read(int fd, char *buf, size_t nbytes) Reads up to nbytes from fd into the buffer starting at buf. How's this for a fair library routine which fulfills this: /* "Pseudo-C" -- not real C, but you get the idea */ int read(int fd, char *buf, size_t nbytes) { int avail = fd->bytes_remaining; if (avail >= nbytes) { copy nbytes bytes from fd into buf[0..nbytes-1]; return nbytes; } else { copy avail bytes from fd into buf[0..avail-1]; /* Try to protect the user a little bit from left over garbage: */ memset(&buf[avail], nbytes-avail, 0); /* zero out buf[avail..nbytes-1] */ return avail; } } (And in your case, of course, the memset hits memory in buf[68..999], and probably trashes about a kilobyte of your other variables.) It seems to me that the contract says "the library routine may always expect to have nbytes of buffer space available at buf". (Perhaps it says this only implicitly, which would be a shame.) I think conforming implementations are free to use that buffer: maybe in a crazed attempt at helpfulness as above, or perhaps it's a fabulously tricky implementation and wants to use the buffer as temporary memory for its low-level file I/O. > The code in question made 100% sure that the data read would never > exceed the buffer size, and I would have been hard pressed to > determine that the code was incorrect. So? Does the specification say that read() will only touch what it _really_ needs to, or all of what the application has told it is available? Unfortunately, the answer seems to be "the specification is kinda vague", so pragmatically surely the more conservative assumption is more reasonable? -- John Marshall <johnm@pec.co.nz> PEC (NZ) Ltd, Marton, New Zealand. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` John Marshall @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) John suggested " /* Try to protect the user a little bit from left over garbage: */ memset(&buf[avail], nbytes-avail, 0); /* zero out buf[avail..nbytes-1] */ return avail;" Interesting, the spec is really not clear on whether this is a valid implementation. I can easily imagine a programmer whose unwritten rules would rule out this interpretation and who might assume that code which (a) preinitialized the buffer to blanks (b) used read to read into part of this buffer should be able to expect trailing spaces and not zeroes, but here again, the spec is insufficiently clear I would say, so this is another nice example of possible portability problems that come from a vague spec. That trailing spaces code will probably work in most (all) implementations of read, and I can imagine some (injudicious? or perhaps informed by a different set of "unwritten rules") programmer assuming it would work. Then an implementatoin would do as John suggested, which certainly is not unreasonable, and lo and behold, another portability problem that could have been prevented by a precise spec. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku ` (2 more replies) 1996-04-12 0:00 ` Gareth Rees 3 siblings, 3 replies; 177+ messages in thread From: Steve Tynor @ 1996-04-09 0:00 UTC (permalink / raw) In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: | 1.3: If I write the code | | int i, j; | | can I assume that (&i + 1) == &j? | | A: Only sometimes. It's not portable, because in EBCDIC, i and j are | not adjacent. What does this have to do with EBCDIC? i and j in this examples are just identifier names of variables -- &i is the address of the variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII or whatever character set you choose) value of the characters 'i' and 'j'. The answer is still "only sometimes", but not for the reason given :-). Or did I miss a Date: header of "1 Apr"? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Programming needn't be like penance or oat bran. Steve Tynor Internet: Steve.Tynor@atlanta.twr.com Tower Technology WWW: http://www.twr.com/ ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` Chet 2 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com>, Steve Tynor <tynor@atlanta.twr.com> wrote: >What does this have to do with EBCDIC? i and j in this examples are >just identifier names of variables -- &i is the address of the >variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII >or whatever character set you choose) value of the characters 'i' and >'j'. The answer is still "only sometimes", but not for the reason >given :-). Or did I miss a Date: header of "1 Apr"? It's a (partial) repost from Peter's contribution to Apr 1. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Dr S.J. Harris 1996-04-10 0:00 ` Chet 2 siblings, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-10 0:00 UTC (permalink / raw) In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com> tynor@atlanta.twr.com "Steve Tynor" writes: >In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir > Kylheku) writes: > >| 1.3: If I write the code >| >| int i, j; >| >| can I assume that (&i + 1) == &j? >| >| A: Only sometimes. It's not portable, because in EBCDIC, i and j are >| not adjacent. > >What does this have to do with EBCDIC? i and j in this examples are >just identifier names of variables -- &i is the address of the >variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII >or whatever character set you choose) value of the characters 'i' and >'j'. The answer is still "only sometimes", but not for the reason >given :-). Or did I miss a Date: header of "1 Apr"? I think you missed the reference to Peter Seebach's (alternative) FAQ. It may well have been first posted on April 1st. Try the following for instance: 9.2: I heard that structures could be assigned to variables and passed to and from functions, but K&R I says not. A: K&R I was wrong; they hadn't actually learned C very well before writing the book. Later, Ritchie got a job at Bell Labs, and worked closely with the authors of C, allowing the 2nd edition of the book to be much more accurate. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Dr S.J. Harris 1996-04-12 0:00 ` Peter Seebach 0 siblings, 1 reply; 177+ messages in thread From: Dr S.J. Harris @ 1996-04-12 0:00 UTC (permalink / raw) In article <829143025snz@genesis.demon.co.uk> fred@genesis.demon.co.uk writes: >In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com> > tynor@atlanta.twr.com "Steve Tynor" writes: > >>In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir >> Kylheku) writes: >> >>| [wit clipped] >>| >>| >I think you missed the reference to Peter Seebach's (alternative) FAQ. It >may well have been first posted on April 1st. Try the following for >instance: > > [humourous quote clipped] > >-- >----------------------------------------- >Lawrence Kirby | fred@genesis.demon.co.uk >Wilts, England | 70734.126@compuserve.com >----------------------------------------- I missed the alternative FAQ too. Is it archived anywhere ? Simon (s.j.harris@ic.ac.uk) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Dr S.J. Harris @ 1996-04-12 0:00 ` Peter Seebach 0 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kljka$c0h@sjsun1.cc.ic.ac.uk>, Dr S.J. Harris <simonh@ic.ac.uk> wrote: >I missed the alternative FAQ too. Is it archived anywhere ? http://www.solon.com/~seebs/c/c-iaq.html and http://www.solon.com/~seebs/c/c-iaq.txt This is not really topical to comp.lang.ada, but anyone who's programmed C may find it a good read. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Tom Watson ` (3 more replies) 2 siblings, 4 replies; 177+ messages in thread From: Chet @ 1996-04-10 0:00 UTC (permalink / raw) If i = j depends on your unit of address. If i is assumed a longword then &i + 4 = &j is true not &i + 1 = &j Chet ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet @ 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach ` (2 subsequent siblings) 3 siblings, 0 replies; 177+ messages in thread From: Tom Watson @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: > If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j > > Chet Bzzzzzt. Sorry wrong answer, and thank you for playing the game. Adding '1' to a pointer implies that you increment the address by the sizeof the object pointed to. Why else is a[i] =(equivalent to)= *(a+i). Now in the original example (deleted before this response) the second object 'j' in this case could be optimized into a register, if its address weren't taken somewhere. All of this can explain why one can't do arithmetic on a 'void *' unless the compiler has made special (non-ANSI) arrangements. Typically sizeof(void) is defined in the compiler as zero so this can't be done (and it produces an error!). -- Tom Watson tsw@3do.com (Home: tsw@johana.com) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Tom Watson @ 1996-04-10 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 3 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: [re: after 'int i, j;', is &i+1 == &j?] >If i = j depends on your unit of address. If i is assumed a longword then > &i + 4 = &j is true > not > &i + 1 = &j This is stupid. A compiler may order the objects in any order it wishes, unless they're in a struct, in which case they must be in declaration order, but there may be arbitrary padding if they're in a struct. But the main stupidity here is that, if i is a longword, &i+1 is one longword "up" from i. Please refrain from correcting my april fools' posting unless you know C, preferably reasonably well. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 3 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Chet wrote " &i + 4 = &j is true not &i + 1 = &j" Surely a couple of :-) are missing here, since this has no relationship to anything real at all (Chet I hope you were just joking, and that it is not that you fail to realize that +1 in C does not mean add one byte!!!!!) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet ` (2 preceding siblings ...) 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 3 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: >If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j Are you serious or is this a (somewhat flat) continuation of the joke? The &i expression yields a pointer to the type of i, and the pointer arithmetic depends on this type. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach ` (2 preceding siblings ...) 1996-04-09 0:00 ` Steve Tynor @ 1996-04-12 0:00 ` Gareth Rees 3 siblings, 0 replies; 177+ messages in thread From: Gareth Rees @ 1996-04-12 0:00 UTC (permalink / raw) Chet <kackman> wrote: > If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j In the C language, the `unit of address' in address arithmetic depends on the type of the address on which the arithmetic happens. Go back and read section 5.4 of K&R2 again. $ uname -sr SunOS 4.1.3_U1 $ cat arith.c #include <stdio.h> int main () { int i; printf("%p + 1 = %p\n", &i, &i+1); return 0; } $ gcc arith.c $ ./a.out f7fffa3c + 1 = f7fffa40 Followups to comp.lang.c only. -- Gareth Rees ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 3 siblings, 2 replies; 177+ messages in thread From: Lawrence Kirby @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Boy, this sure has wandered! THe original issue was the semantic behavior >of read. Unlike other unices, in Linux, the bounds check for the read >buffer is based on the requested count, rather than the actual count >of data bytes read. It is hard to say either approach is right or >wrong, but they are different enough to cause portability problems. Both approaches meet the relevant standards and are correct. Only broken code has portability problems, but that's nothing new. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Lawrence Kirby @ 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Szu-Wen Huang @ 1996-04-08 0:00 UTC (permalink / raw) Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: : >Boy, this sure has wandered! THe original issue was the semantic behavior : >of read. Unlike other unices, in Linux, the bounds check for the read : >buffer is based on the requested count, rather than the actual count : >of data bytes read. It is hard to say either approach is right or : >wrong, but they are different enough to cause portability problems. : Both approaches meet the relevant standards and are correct. Only broken : code has portability problems, but that's nothing new. Shouldn't true portability mean that even bugs are cross-platform and fail reliably? ;) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Fergus Henderson ` (2 more replies) 0 siblings, 3 replies; 177+ messages in thread From: James McIninch @ 1996-04-08 0:00 UTC (permalink / raw) Szu-Wen Huang (huang@mnsinc.com) wrote: : Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : : In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: : : >Boy, this sure has wandered! THe original issue was the semantic behavior : : >of read. Unlike other unices, in Linux, the bounds check for the read : : >buffer is based on the requested count, rather than the actual count : : >of data bytes read. It is hard to say either approach is right or : : >wrong, but they are different enough to cause portability problems. : : Both approaches meet the relevant standards and are correct. Only broken : : code has portability problems, but that's nothing new. : Shouldn't true portability mean that even bugs are cross-platform and : fail reliably? ;) No. When it says "undefined", it means "undefined". There's no way to make undefined behavior portable, that's why it's undefined. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch @ 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Szu-Wen Huang 2 siblings, 2 replies; 177+ messages in thread From: Fergus Henderson @ 1996-04-08 0:00 UTC (permalink / raw) james@amber.biology.gatech.edu (James McIninch) writes: >Szu-Wen Huang (huang@mnsinc.com) wrote: >: Shouldn't true portability mean that even bugs are cross-platform and >: fail reliably? ;) > >No. I strongly disagree -- Szu-Wen Huang is right. >When it says "undefined", it means "undefined". There's no way to make >undefined behavior portable, that's why it's undefined. Nope, you've got cause and effect backwards. There's no way to make undefined behavior portable *because* it is undefined. If a language has constructs with undefined behaviour, this will lead to portability problems. But some languages have fewer areas of undefined behaviour than others. Some languages don't have any undefined behaviour at all. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Fergus says "Nope, you've got cause and effect backwards. There's no way to make undefined behavior portable *because* it is undefined. If a language has constructs with undefined behaviour, this will lead to portability problems. But some languages have fewer areas of undefined behaviour than others. Some languages don't have any undefined behaviour at all." True enough, but this is only achievable by going to a fairly high level of abstraction. For example SNOBOL4 (or SPITBOL) programs are totally portable, with no undefined behavior at all. But if you have a language that can twiddle bits at a low level, it is hard to see how undefined behavior could be eliminated completely. It is definitely true that constructs with undefined (or non-deterministic) behavior, can lead to portability problems. Remember portable programs are portable by definition -- it's possible to write portable programs in any language. Portability problems are precisely caused by constructs that render progams non-portable. This is obvious, but worth saying, because for example Peter tends to say "What portability problems, your code is just wrong :-)" Back to non-determinism. A language can have totally defined semantics and still have non-deterministic semantics. For example in SETL, a language with no undefined semantics: x := arb {1,2,3,4}; selects an arbitrary element of the set, and puts any of 1,2,3,4 in X. The semantics of SETL is well defined (although as usual the presence of such non-determinism complicates the formal semantics). However, it is now possible to write non-portable SETL programs that incorrectly depend on "knowing" that in practice the compiler in use always implements arb by selecting the minimum element (a perfectly correct implementation, arb does not mean random!). A similar case arises in Ada with the select statement, which is free to select any open alternative non-determinisitically, or with the semantics of expression evaluation, where it is non-determinstic whether the right or left operand of an operator is evaluated first. The second case could be eliminated from the language, but anyting invollving timing is likely to lead to some non-eliminatable non-determinism. \x1adp ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-20 0:00 ` Fergus Henderson 1 sibling, 1 reply; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Fergus Henderson wrote... > james@amber.biology.gatech.edu (James McIninch) writes: > > >Szu-Wen Huang (huang@mnsinc.com) wrote: > >: Shouldn't true portability mean that even bugs are cross-platform and > >: fail reliably? ;) > > > >No. > > I strongly disagree -- Szu-Wen Huang is right. > Wrong! As a developer, I *wish* that bugs were reproducible enough to actually be portable. Would make the little devils a lot easier to find. > >When it says "undefined", it means "undefined". There's no way to make > >undefined behavior portable, that's why it's undefined. > > Nope, you've got cause and effect backwards. There's no way to make > undefined behavior portable *because* it is undefined. If a language > has constructs with undefined behaviour, this will lead to portability > problems. But some languages have fewer areas of undefined behaviour > than others. Some languages don't have any undefined behaviour at > all. > Hmm. I don't know about other languages, but the whole reason things are undefined in C/C++ is because all the feuding UNIX and PC developers wrote a zillion incompatible libraries that often relied on bizarre side-effects and "fallout" behavior. ANSI/ISO made such behavior "undefined" meaning that no well-behaved, well-formed, *strictly portable* program would use such a thing. That way, compiler vendors could support the undefined behavior however they wanted or not at all, to retain maximum back-compatibility. This is in contrast to "implementation-defined" behavior, which means that the vendor has to do *something* about the weirdness and document it. Undefined stuff can do whatever your compiler vendor wants it to. And it's undefined *because* it's not portable, not even to the extent that it may or not exist on your machine. Bradd ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-20 0:00 ` Fergus Henderson 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 177+ messages in thread From: Fergus Henderson @ 1996-04-20 0:00 UTC (permalink / raw) Bradd W. Szonye <bradds@ix.netcom.com> writes: >On Monday, April 08, 1996, Fergus Henderson wrote... >> james@amber.biology.gatech.edu (James McIninch) writes: >> >> >Szu-Wen Huang (huang@mnsinc.com) wrote: >> >: Shouldn't true portability mean that even bugs are cross-platform and >> >: fail reliably? ;) >> > >> >No. >> >> I strongly disagree -- Szu-Wen Huang is right. > >Wrong! I think you have been confused by a double negative, and that your "Wrong!" comment was directed at the viewpoint espoused by James McInich, with which I was disagreeing. >As a developer, I *wish* that bugs were reproducible enough to >actually be portable. Would make the little devils a lot easier to find. I fully agree. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Fergus Henderson @ 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Saturday, April 20, 1996, Fergus Henderson wrote... > Bradd W. Szonye <bradds@ix.netcom.com> writes: > > >On Monday, April 08, 1996, Fergus Henderson wrote... > >> james@amber.biology.gatech.edu (James McIninch) writes: > >> > >> >Szu-Wen Huang (huang@mnsinc.com) wrote: > >> >: Shouldn't true portability mean that even bugs are cross-platform and > >> >: fail reliably? ;) > >> > > >> >No. > >> > >> I strongly disagree -- Szu-Wen Huang is right. > > > >Wrong! > > I think you have been confused by a double negative, and that your > "Wrong!" comment was directed at the viewpoint espoused by James > McInich, with which I was disagreeing. > > >As a developer, I *wish* that bugs were reproducible enough to > >actually be portable. Would make the little devils a lot easier to find. > > I fully agree. > > -- > Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit > WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" > PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. > Oops, didn't mean to make myself look like an idiot. I wasn't trying to tell Fergus that he was wrong, I was rather agreeing with him that I strongly disagreed with the post before him. Class term project: Write a yacc parser to disambiguate what I just said. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Szu-Wen Huang 2 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) James says "No. When it says "undefined", it means "undefined". There's no way to make undefined behavior portable, that's why it's undefined." Actually, things are not quite so simple. In practice compiler vendors often go to quite a bit of trouble to make sure that things that people expect to work, do in fact work they way they expect, even if the standard says that the behavior is undefined. For example, in Fortran-66, it was undefined what happened in a DO loop if the end-points were the "wrong" way round, but in practice the expectation was that the loop would execute once, so all F66 compilers I know work that way. Similarly in Fortran, people expect large arrays to be passed by reference, and count on it, so even though the standard says that it is undefined whether they are passed by reference or value, all compilers do in fact use pass by reference and a lot of highly portable code depends on this fact. Highly portable here is not some kind of theoretical label about conformance, it is an empirical observation that the code works on all platforms. Almost all languages have some level of expectations about what works that go beyond the standard. For example, in C, people do all sorts of things with pointers that are undefined in ANSI terms, and yet the resulting programs are in fact highly portable. In Ada, as another example, there is a strong expectation that if an out parameter is not assigned in a procedure, then its valud is undefined and should not be accessed on return, but in fact it is permissible to raise Program_Error in this case. Ada/Ed used to do this, and it caused major chaos with a lot of otherwise portable programs. Yes, the programs were technically wrong, but in the real world, Ada/Ed changed, not all the programs out there. A competent compiler tries to implement 100% of the required standard functionality, plus as much as possible of the expected behavior that goes beyond this standard, consistent with not damaging the quality of code, or the performance of the compiler, too severely. The examples above are just scattered examples, every language I know has quite a long list of such "common beliefs" that are in fact wrong. A more delicate problem arises when an existing compiler has bugs with respect to the standard, and you are trying to be compatible with both the standard and the existing compiler. In this case, some delicate compromises may be necessary. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 177+ messages in thread From: Keith Thompson @ 1996-04-11 0:00 UTC (permalink / raw) In <dewar.828992408@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: [...] > A competent compiler tries to implement 100% of the required standard > functionality, plus as much as possible of the expected behavior that > goes beyond this standard, consistent with not damaging the quality > of code, or the performance of the compiler, too severely. On the other hand, it's tempting to suggest that a compiler should implement 100% of the required functionality and as *little* as possible of the expected behavior that goes beyond the standard. For example: As many instances as possible of erroneous execution are detected and raise Program_Error. No predefined integer types other than Integer, and no predefined floating-point types other than Float. Elaboration order is chosen to *maximize* the likelihood of access-before-elaboration errors. Unchecked_Conversion behaves strangely in some cases. Access values are not addresses. Different access types are represented differently. The internal representation of a null access value or address is not 0. Perverse task scheduling to the extent allowed by the standard. Similar ideas can be applied to languages other than Ada. Porting existing code to such a compiler could be an excellent way to filter out bugs and non-portable constructs. More realistically, it might be a good idea to implement this kind of thing as a compiler option; the default behavior should be more forgiving. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson @ 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Robert Dewar wrote... > [...] In practice compiler vendors > often go to quite a bit of trouble to make sure that things that people > expect to work, do in fact work they way they expect, even if the standard > says that the behavior is undefined. In the desktop computing world, where the IBM's and Microsofts send the standards instead of the ANSI's and ISO's, this concept is known as a "de facto standard." Translation from the Latin: it works 'cuz everybody does it that way, not 'cuz ISO-9899/1990 sez so. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 2 siblings, 1 reply; 177+ messages in thread From: Szu-Wen Huang @ 1996-04-08 0:00 UTC (permalink / raw) James McIninch (james@amber.biology.gatech.edu) wrote: : Szu-Wen Huang (huang@mnsinc.com) wrote: : : Shouldn't true portability mean that even bugs are cross-platform and : : fail reliably? ;) : No. When it says "undefined", it means "undefined". There's no way to make : undefined behavior portable, that's why it's undefined. It's a joke, lighten up ;). ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Szu-Wen said It's a joke, lighten up ;). (referring to his comment about portability of behavior) Actually the joke is on you, because the comment you made is not a joke at all but instead a very important point, around which a lot of language design decisions focus. An obvous goal of any language design is to minimize or eliminate undefined and non-deterministic behavior. These goals are often not net because of two important considerations: 1. Over specifying can lead to inefficient code (e.g. requiring left to right evaluation) 2. Some features (low level bit twiddling, tasking, etc.) may make it desirable semantically to introduce undefined or ND behavior. Debating the compromises here is a major activity of language design. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Robert Dewar wrote... > Szu-Wen said > > > It's a joke, lighten up ;). > > > (referring to his comment about portability of behavior) > > Actually the joke is on you, because the comment you made is not a joke > at all but instead a very important point, around which a lot of language > design decisions focus. > > An obvous goal of any language design is to minimize or eliminate > undefined and non-deterministic behavior. > > These goals are often not net because of two important considerations: > > 1. Over specifying can lead to inefficient code (e.g. requiring left to > right evaluation) > > 2. Some features (low level bit twiddling, tasking, etc.) may make it > desirable semantically to introduce undefined or ND behavior. > > Debating the compromises here is a major activity of language design. > > True, those are goals of language design. However, they're not goals of language standarization. The goals of *that* are to codify existing practice. Throughout the C language, if it came to a choice between breaking existing code or leaving something undefined, ANSI made it undefined half the time and "implementation-defined" the other half. The demands of C programmers on the language's efficiency on the local machine made it harder still to come up with unbreakable rules. Bradd ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku ` (2 more replies) 1 sibling, 3 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) With respect to read (Linux unusual behavior), Lawrence said "Both approaches meet the relevant standards and are correct. Only broken code has portability problems, but that's nothing new." Can you quote the relevant standard. No description of read I ever saw was detailed or precise enough to say what the requirements on the caller are. Lots of code is portable and broken, lots of code is (deliberately) non-portable and definitely not broken. Lots of code is carefully written to be portable, but runs into bugs in supposedly conforming implementations. Lots of code uses features that are useful, but for which no standard exists, and hence may run into portability problems. Equating portability with non-brokenness in general is naive. Even in an environment with a definite standard, writing portable code requires a lot more than just adhering to the letter of the standard! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987544@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >With respect to read (Linux unusual behavior), Lawrence said > >"Both approaches meet the relevant standards and are correct. Only broken >code has portability problems, but that's nothing new." > >Can you quote the relevant standard. No description of read I ever saw >was detailed or precise enough to say what the requirements on the caller >are. > >Lots of code is portable and broken, lots of code is (deliberately) >non-portable and definitely not broken. Lots of code is carefully >written to be portable, but runs into bugs in supposedly conforming >implementations. Lots of code uses features that are useful, but for >which no standard exists, and hence may run into portability problems. In this case, it is safe to assume that the caller of read() had better not lie to the system call. The buffer size is the de-facto ``advertized'' buffer size, and all of the buffer up to the given size should be backed by valid storage. It would not even occur to me to advertize a buffer of size N, but pass a pointer to a buffer of size M < N to the POSIX read() function, or in any way rely on the nature of the checking done by the kernel. This is so deeply entrenched in the realm of common sense that it isn't even worth mentioning in a standard document! Nevertheless, I have access to the POSIX.1 standard and will look into this. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Mike Shannon 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) "This is so deeply entrenched in the realm of common sense that it isn't even worth mentioning in a standard document! Nevertheless, I have access to the POSIX.1 standard and will look into this." This seems complete nonsense. There are two possible semantics that ould be defined for read (buffer must be at least size of the read argument, or buffer must be at least size of data read). Both are easy to specify, both are easy to implement. You cannot rely on common sense (especially dubious reasoning about kernels and what not that are totally irrelevant to the semantic specification). The idea that specs are derived from implementations (either by looking at the implementation, or reasoning about it with "common sense" or otherwise) is completely unacceptable! (though unfortunately very common, especially when people are writing in a language that does not make a big deal about separating spec and implementation details). My only at-hand sources are K&R, which has nothing whatever to say on the subject, the Zortech C++ reference, which also has nothing to say, (both describe read, but say nothing about the buffer length), and the Microsoft Runtime Reference which talks about "attempting to read n bytes", but is otherwise unclear. We are after all dealing with a language interface where in practice the proper check (whichever it is) cannot be made, because the called routine does not know the length of the buffer passed. I think a natural default assumption, in the absence of any statement to the contrary, is that the bytes are blindly read into the buffer, and disaster strikes if the number of bytes read is greater than the buffer length, but otherwise all is well. Unless there is a VERY clear statement of semantics to the contrary, I don't see how anyone can call code that makes this assumption obviously broken. This is of course a rather trivial detail but is instructive with regard to the importance of writing precise specs. Kazimir's claim that the spec obviously requires that the buffer length match the requested, rather than actual length, based on some dubious reasoning about likely implementation models is just the sort of thing that needs to be eliminated from programming practices. Specs need to be made precise, so that a caller knows EXACTLY what the requirements are without having to guess, or, worse still, examine the actual implementation code. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` Mike Shannon 1 sibling, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829048603@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"This is so deeply entrenched in the realm of common sense that it isn't even >worth mentioning in a standard document! Nevertheless, I have access to the >POSIX.1 standard and will look into this." > >This seems complete nonsense. There are two possible semantics that ould >be defined for read (buffer must be at least size of the read argument, >or buffer must be at least size of data read). Both are easy to specify, >both are easy to implement. You cannot rely on common sense (especially >dubious reasoning about kernels and what not that are totally irrelevant >to the semantic specification). The idea that specs are derived from You are right. This has more to do with those unwritten rules that you mentioned earlier (my wording, not yours). Expecting that you only have to specify a buffer large enough to hold the actual data that will be read, while telling the read function that the buffer is bigger is just not reasonable. Suppose you don't know whether you may or may not lie in specifying the buffer size, since no documentation explicitly allows it nor prohibits it. Which way do you make the decision? Which method is safer? Giving a buffer that is as large as you promise it is, or giving a smaller buffer? There is no telling that even if you know 100% that so many bytes will be read, the rest of the buffer will not be accessed. >implementations (either by looking at the implementation, or reasoning >about it with "common sense" or otherwise) is completely unacceptable! You are the one who advocates empirical approaches: in a recent posting you said that if something works on all the platforms, it is portable regardless whether it invokes undefined behavior. >(though unfortunately very common, especially when people are writing in >a language that does not make a big deal about separating spec and >implementation details). > >My only at-hand sources are K&R, which has nothing whatever to say on >the subject, the Zortech C++ reference, which also has nothing to say, >(both describe read, but say nothing about the buffer length), and >the Microsoft Runtime Reference which talks about "attempting to >read n bytes", but is otherwise unclear. > >We are after all dealing with a language interface where in practice the >proper check (whichever it is) cannot be made, because the called routine >does not know the length of the buffer passed. I think a natural default >assumption, in the absence of any statement to the contrary, is that the >bytes are blindly read into the buffer, and disaster strikes if the number >of bytes read is greater than the buffer length, but otherwise all is well. >Unless there is a VERY clear statement of semantics to the contrary, I >don't see how anyone can call code that makes this assumption obviously >broken. You are right about that, of course. You can't call the code ``obviously broken'', but I would call the programmer imprudent. >This is of course a rather trivial detail but is instructive with regard >to the importance of writing precise specs. Kazimir's claim that the spec >obviously requires that the buffer length match the requested, rather >than actual length, based on some dubious reasoning about likely >implementation models is just the sort of thing that needs to be >eliminated from programming practices. Specs need to be made precise, But here there is a clear lack of precise specs! I'm advocating the _safer_, more _prudent_ assumption. There is clearly more opportunity to screw up if you falsely represent your buffer size to a system call or library function. Even if it were OK to do so on every system, the program may later change such that the hidden assumption is violated. Suddenly, not 68, but 113 bytes come from the file, for some reason, and the program fails of behaves strangely. Even all those UNIXes that check against the actual transfer size rather than buffer size will not necessarily catch this, since the check is usually only good to the granularity of a page. The current maintainer, of course, doesn't know what hack had been perpetrated and may be faced with tracing down problems that could have been avoided. >so that a caller knows EXACTLY what the requirements are without having >to guess, or, worse still, examine the actual implementation code. I agree. I was dismayed when I was not able to find a definitive answer in the POSIX.1 standard itself. These sorts of things should be specified so that the programmers don't have to rationalize about what is likely to be safer. Here is my ``dubious'' reasoning laid out step by step, so criticize at will: 1. In the C language, the size of an object has a specific meaning. If I malloc 100 bytes, or declare 100 bytes in static or automatic storage, the size of that object is not 101, not 1000, but 100 bytes. (Granted, the third argument of read() is not usually referred to as the _size_ of the object pointed at by the second argument, but as a _count_ of bytes to be read into the buffer. It does have a size_t type which is used in ANSI C to hold the sizes of objects, and is the return type of the sizeof operator). 2. No documentation has ever explicitly stated that the argument may be greater than the actual size of the object to which a pointer can be given. 3. In choosing between two alternatives, choose the safer one, all else being equal. 4. Even if the apparently less safe alternative is actually safe, it depends on preconditions in the program which may change, namely assumptions about how many bytes are left in the particular file, pipe or whatever. This will could cause problems in the maintenance cycle of the software. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir has now moved on to (perfectly reasonable) discussions of sound programming practices, with which I of course do not disagree. But that was not what caused me to raise the read issue in the first place. I used it merely as an example of a portability problem caused by an unclear specification. Seems to me that Kazimir's failure to find anything approximating a clear spec, and talk of unwritten rules, means he agrees wit me :-) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829079393@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir has now moved on to (perfectly reasonable) discussions of >sound programming practices, with which I of course do not disagree. > >But that was not what caused me to raise the read issue in the first >place. I used it merely as an example of a portability problem caused >by an unclear specification. Seems to me that Kazimir's failure to >find anything approximating a clear spec, and talk of unwritten >rules, means he agrees wit me :-) Right. The discussion was not of programming practices, but of implementation. I think this sums it up: Seebach and Myself: in the absence of clarity in a standard, as a programmer follow the best rational inference to the safest/weakest assumption; program defensively. Then you don't have to worry about which choice is made in the implementation. Dewar: in the absence of clarity in a standard, as an implementor, follow the pack. Look at what most implementations do, and stick to the unwritten standards of the community. As a programmer, if you do the former, you don't have to particularly worry whether an implementation does the latter. For example, because I don't assume that select() will not modify the timeval structure, I don't have to care whether it does or not. The trouble is that the combined effect of the two motivations results in nothing being done to fix the standards. Good programmers are careful anyway, so they don't care, and those who are not careful are forgiven by most of the implementations, so they don't care (or don't even know) either. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Kazimir says "Dewar: in the absence of clarity in a standard, as an implementor, follow the pack. Look at what most implementations do, and stick to the unwritten standards of the community." That of course completely misunderstands my position and Kazimir's failure to undertand the central issue here is a great illustration of my central point. In fact I could not have asked for anyone to make the point more clearly. I brought up this thread not as a discussion of proper programming practices, but of the importance of specs, and to give an example of portability problems caused by inaccurate specs. Kazimir's view is "so what if the specs are vague, never mind, if people are "rational" or follow "unwritten rules", then it probably won't matter much. The trouble is that it absolutely *does* matter, and it matters much! If programmers continue to follow Kazimir's casual attitude towards specs, then we continue to get libraries, and, as we see in the case of POSIX, even standards, that are unacceptably vague. I am not asking for formal specifications, although with library routines like this it would not be too hard, and would definitely be useful, but I think people need to have more formal training in semantics, so that they understand the critical issue of clear specifications. The bravado attitude of Kazimir and Peter -- "people shouldn't make errors, if they do they get what they deserve", or "people should think clearly, real programmers don't need specs [to be fair that is Kazimir and not Peter]" is actually often more of a menace than incompetence. I have often seen big programs get into horrible trouble because a really clever programmer thought that rigorous engineering could be replaced by programming brilliance. As I have said many times, the details of the read issue are not that important. It is simply a case where different implementatoins have subtly different specs, and consquently a program that is semantically correct in one implmentation is wrong in another. The only cure to this problem is clear specification at an abstract, implementation-independent level. People who think that they can overcome the lack of such clear abstract specifications by guessing what is rational or reasonable are fooling themselves badly. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 2 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829135457@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir says > >"Dewar: in the absence of clarity in a standard, as an implementor, follow the >pack. Look at what most implementations do, and stick to the unwritten >standards of the community." > >That of course completely misunderstands my position and Kazimir's failure >to undertand the central issue here is a great illustration of my central >point. In fact I could not have asked for anyone to make the point >more clearly. > >I brought up this thread not as a discussion of proper programming >practices, but of the importance of specs, and to give an example >of portability problems caused by inaccurate specs. > >Kazimir's view is "so what if the specs are vague, never mind, if people >are "rational" or follow "unwritten rules", then it probably won't matter >much. > >The trouble is that it absolutely *does* matter, and it matters much! >If programmers continue to follow Kazimir's casual attitude towards >specs, then we continue to get libraries, and, as we see in the case >of POSIX, even standards, that are unacceptably vague. You are quoting me unfairly and out of context, as anyone who follows back to the article your are replying to can plainly see. At the bottom I say: %As a programmer, if you do the former [try to do your best to live with %imprecise specs---you have work to do after all!], you don't have to %particularly worry whether an implementation does the latter. For example, %because I don't assume that select() will not modify the timeval structure, I %don't have to care whether it does or not. % %The trouble is that the combined effect of the two motivations results in %nothing being done to fix the standards. Good programmers are careful anyway, %so they don't care, and those who are not careful are forgiven by most of the %implementations, so they don't care (or don't even know) either. This clearly shows that I also think that it *does* matter. The standards don't get fix because programmers get used to working around the flaws, and implementors follow unwritten rules (which you advocate: you are the one who said that Linux should so things like the other UNIXes to alleviate portability problems). >I am not asking for formal specifications, although with library >routines like this it would not be too hard, and would definitely >be useful, but I think people need to have more formal training >in semantics, so that they understand the critical issue of >clear specifications. I however am asking for formal specifications. >The bravado attitude of Kazimir and Peter -- "people shouldn't make >errors, if they do they get what they deserve", or "people should >think clearly, real programmers don't need specs [to be fair that >is Kazimir and not Peter]" is actually often more of a menace >than incompetence. I have often seen big programs get into horrible That is completely false. I never said any such thing. I advocated a certain course of rational action in the absence of clarity in the spec. I did not state that one should get what one deserves, or that the specs are not needed. Clearly, how can anyone advocate the that viewpoint ``real programmers'' do not need specs? All I did was state that when you have specs that are not perfectly comprehensive and can you are aware that they can be interpreted in more than one way, pick the safer alternative if you can. If you are not aware, I don't claim that you are a bad programmer. In fact I pointed out how I was bitten myself by the differences in select() semantics, and that I sympathize with your viewpoint due to my first-hand experience. >trouble because a really clever programmer thought that rigorous >engineering could be replaced by programming brilliance. > >As I have said many times, the details of the read issue are not that >important. It is simply a case where different implementatoins have >subtly different specs, and consquently a program that is semantically >correct in one implmentation is wrong in another. The only cure to this >problem is clear specification at an abstract, implementation-independent >level. People who think that they can overcome the lack of such clear Yes, that is the cure. But the individual programmer doesn't have access to such a powerful remedy. Standards take time to evolve and crystallize. I may _want_ read() to work a certain way but the task of convincing the whole world to move over to my precise conception is not easy! Not every programmer can afford to get outraged and calls ANSI, IEEE or ISO to call a new committee together to fix something and than wait until it's done! I'm a little upset about POSIX, but so be it (for now). This is something that I don't control. Maybe one day I will sit on a standardization committee and will make sure that nothing falls through the cracks, but right now I'm just a standards _user_, for better or worse. >abstract specifications by guessing what is rational or reasonable >are fooling themselves badly. Or maybe they are just getting work done the best they can with what is available, like I'm sure you are! The GNAT runtime calls read() happily. It messed-up under Linux, and was fixed. The problem was brought to prominent attention, which kick-started the reasoning process that led to a more prudent interpretation of standard and an implementation that works under Linux _and_ the previous ports. This is what anyone would have done under the circumstances. I never claimed that this would have never happened to a ``real programmer'', and don't wish to be interpreted in the worst possible way if there is misunderstanding. In the absence of clarity in any of my postings, please assume the least harmful or arrogant interpretation. :) -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 177+ messages in thread From: Robert A Duff @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgmlpINN7aj@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >In the absence of clarity in any of my postings, please assume the least >harmful or arrogant interpretation. :) Usenet would be a better place if everybody did that. ;-) ;-) - Bob ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) Do what I do in this situation. Think about the problem and try to decide what makes the most sense. If it doesn't make sense, look it up. If your first attempt doesn't work, look it up. If you don't find the answer in you compiler's manuals (note the *comiler's*, not the standards, because few compilers are all that conformant), use a different function. Write your own. Write a letter to your senator. Whatever. For comparison, consider other functions that fill buffers, like sprintf or scanf. They don't take a byte count at all. They just assume that the programmer has the sense to provide a buffer big enough for the data you ask for. Providing a length argument doesn't change this kind of common sense. Bradd ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) Bradd says "For comparison, consider other functions that fill buffers, like sprintf or scanf. They don't take a byte count at all. They just assume that the programmer has the sense to provide a buffer big enough for the data you ask for. Providing a length argument doesn't change this kind of common sense." Ah, but see that this common sense is EXACTLY wrong here. Yes indeed, I can see one style of common sense that says that the critical thing is to provide a bug enugh buffer to accomodate the data you ask for, bug remember that the semantics of read is that "the data you are asking for" is either count data or all the data that is there, which ever is smaller. So if there are only 5 bytes and the count is 10, then you are asking for 5 bytes to be read, but the whole point of this rather tedious thread is that this brand of common sense is wrong here. Incidentally, Bradd;s first paragraph, about just trying things till they work, and not reading the standard, is a rather appalling commentary on the state of the way that many programmers work if you ask me. This kind of attitude is what causes a LOT of portability problems in read life. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert Dewar wrote... > Bradd says > > "For comparison, consider other functions that fill buffers, like sprintf > or scanf. They don't take a byte count at all. They just assume that the > programmer has the sense to provide a buffer big enough for the data you > ask for. Providing a length argument doesn't change this kind of common > sense." > > Ah, but see that this common sense is EXACTLY wrong here. Yes indeed, > I can see one style of common sense that says that the critical thing > is to provide a bug enugh buffer to accomodate the data you ask for, > bug remember that the semantics of read is that "the data you are > asking for" is either count data or all the data that is there, which > ever is smaller. > > So if there are only 5 bytes and the count is 10, then you are asking > for 5 bytes to be read, but the whole point of this rather tedious > thread is that this brand of common sense is wrong here. So you're saying that if I allocate a 10-byte buffer, and specify a count of 10 bytes, but there are only 5 bytes in the file, I would cause an error? I missed the *very* beginning of the thread that asked the original question (please don't flame me, I'm posting on general principles here), but I still don't see how my common sense would get me in trouble here. If I provide a 10-byte buffer to strncpy and and specify a count of 10 bytes, I might only get 5 "useful" bytes there, too. But I'm not going to lose any sleep over it. Now common sense, *can* get you in trouble. Take the file functions; almost all of them expect the FILE* first, but a couple want it last. That can get you in trouble if you aren't using prototypes, but fortunately C++ protects us from *that*. > Incidentally, Bradd;s first paragraph, about just trying things till they > work, and not reading the standard, is a rather appalling commentary on > the state of the way that many programmers work if you ask me. This kind > of attitude is what causes a LOT of portability problems in read life. Did I ever say I don't read the standard? I keep 9899-1990 and the ARM by the keyboard, and the C++ DWP online in HTML. When not in doubt, I let experience and common sense guide me. I get a lot more done that way than if I look everything up in the book. When in doubt, however, I read the compiler's online help/man page or the standard, depending on which is more accessible and what I'm looking for. Nonstandard stuff is only in the compiler's guide, but the standard is the final word on portability (sometimes). I don't take your last comment as a personal flame however; you're right! Too many programmers work entirely by the seats of their corduroy pants. I'm not one of them, however. With 15 years of programming experience, 6 years of C++ experience, and having taught people some of the language's finer points, my "common sense" is a little more sophisticated than an unprofessional hack's. -- Bradd W. Szonye (bradds@ix.netcom.com), Doubleplus Corporation "To chill or to pop a cap in my dome, whoomp, there it is." -- Hamlet, Prince of Denmark ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 177+ messages in thread From: Mike Shannon @ 1996-04-10 0:00 UTC (permalink / raw) In <dewar.829048603@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: >There are two possible semantics that ould >be defined for read (buffer must be at least size of the read argument, >or buffer must be at least size of data read). Both are easy to specify, >both are easy to implement. You cannot rely on common sense > ... I'm a latecomer to this dispute, but this is not smart: char buf[100]; read(fd,buf,1000); Common sense, which tells me not to do such things, is a welcome ally. >We are after all dealing with a language interface where in practice the >proper check (whichever it is) cannot be made, because the called routine >does not know the length of the buffer passed. I think a natural default >assumption, in the absence of any statement to the contrary, is that the >bytes are blindly read into the buffer, and disaster strikes if the number >of bytes read is greater than the buffer length, but otherwise all is well. >Unless there is a VERY clear statement of semantics to the contrary, I >don't see how anyone can call code that makes this assumption obviously >broken. SIGSEGV is invited, not by any "statement of semantics", but by careless code. If you use these functions without reasonable care, then you experience the consequences. If you do this for a living, you learn not to waste time on unnecessary chances. >Specs need to be made precise, >so that a caller knows EXACTLY what the requirements are without having >to guess, or, worse still, examine the actual implementation code. Good specs do not write good code - good programmers do. By the way, how did all this get started? Mike Shannon Houston, Texas <!> Once we had computers and dumb terminals. <!> Now we have computers and stupid terminals. <!> Thanks, Microsoft. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 2 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Mike said "SIGSEGV is invited, not by any "statement of semantics", but by careless code. If you use these functions without reasonable care, then you experience the consequences. If you do this for a living, you learn not to waste time on unnecessary chances." No, that's confused. First of all, the clear specifications of most specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for the call in question. Linux may or may nt give a SIGSEGV depending on the luck of the draw (where the buffer is in memory). Basically the original code (not mine incidentally, I never write in C these days), was taking a short cut that was reasonably safe on most systems, and this "bug" might have survived for ever in the absence of the check in Linux + the happenstance that the buffr was near the end of memory. True, if someone appended to the file while it was being compiled, disaster could have struck, but most compilers and assemblers tend to assume that this is unlikely and of course in systems with decent file protection it is impossible. So for example, the code as originally written is 100% reliable on OS/2. Of course writing portable code requires careful consideration of various possibilities, and failure to be careful certainly results in portability problems. But it is clear that if the spec for read had been clearer, this bug would NOT have been present in the first place! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829101156@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >No, that's confused. First of all, the clear specifications of most >specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for >the call in question. Linux may or may nt give a SIGSEGV depending >on the luck of the draw (where the buffer is in memory). I suspect what you're seeing is an obvious bug in their specs. As written, the spec on at least one system also guarantees not to give a fault for char buf; read(fd, &buf, 1000); even if there are 1000 bytes available, because the check is only specified for whether the pointer given points to a valid object. >Of course writing portable code requires careful consideration >of various possibilities, and failure to be careful certainly >results in portability problems. But it is clear that if the >spec for read had been clearer, this bug would NOT have been >present in the first place! I doubt it. I would bet that whoever wrote it did not give adequate consideration to it, and did not check the spec in any detail. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Peter Seebach @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Peter wrote >I suspect what you're seeing is an obvious bug in their specs. As >written, the spec on at least one system also guarantees not to give >a fault for > char buf; > read(fd, &buf, 1000); >even if there are 1000 bytes available, because the check is only specified >for whether the pointer given points to a valid object. No, that's incorrect. All versions of the spec that I have read are quite clear that this call would cause undefined overwriting of data. I say clear here in an informal sense, since these are of course informal specs, but no one could read any of these specs and have any question but that the above has undefined behavior if 1000 bytes are read. I think Peter is misreading the spec here, deliberately or otherwise. >I doubt it. I would bet that whoever wrote it did not give adequate >consideration to it, and did not check the spec in any detail. You would be quite wrong, and you would lose your bet. Some programmers are very aware of specifications as they program! The actual thought process here was very definitely a concious observation that the last call was "safe" because it could not overwrite data, and an assumption that overwriting data was the only undefined semantics involved. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 2 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Mike notes/asks >I'm a latecomer to this dispute, but this is not smart: > > char buf[100]; > read(fd,buf,1000); > >By the way, how did all this get started? Good question, I don't particularly see any dispute here. Obviously noone ever wrote code so obviously peculiar as your above example! The exact code, which appeared in the GNAT runtime was a loop to read a file that had in the loop read(fd,p,16*1024); to read the file in chunks of 16K. The last call exactly filled the remaining buffer which had been sized to exactly fit the size of the file. This code worked fine for a long time on nearly all systems, and in fact if you read the spec should work on most systems. But it failed on Linux (and was immediately corrected, no big deal!) and the reason is that Linux has subtly different semantics. The issue was whether any of the so-called specs for read (POSIX or SPEC1170) were clear enough to determine which of the two observed implementation models was "right". Turns out that no spec we could find (no one seems to have SPEC1170) precisely defined the specs. The wandering off into whether the code involved was or was not a good idea (obviously it was not!) is irrelevant. I was just using this as an example of a portability problem caused by weak specifications. Peter takes the odd view that it is not a portability problem because the code was not well defined, and therefore not portable. This seems a bit of a useless observation--Peter has determined that only portable code is portable, not terribly useful :-). Kazimir at first claimed that the spec clearly favored the Linux interpretation, then could not find any evidence and appealed to unwritten rules :-) But just to be clear, there is no dispute over whether the code as written was a good idea, it was simply an interesting example of a portability problem resulting from weak specs. The disussion showed to an extent that surprised even me that the specs for such routines are really horribly weak, at least in POSIX. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert A Duff 1996-04-11 0:00 ` Robert Dewar 2 siblings, 2 replies; 177+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kets3$ic0@news-s01.ny.us.ibm.net> mshan@ibm.net "Mike Shannon" writes: > In <dewar.829048603@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > > >There are two possible semantics that ould > >be defined for read (buffer must be at least size of the read argument, > >or buffer must be at least size of data read). Both are easy to specify, > >both are easy to implement. You cannot rely on common sense > > ... > > I'm a latecomer to this dispute, but this is not smart: > > char buf[100]; > > read(fd,buf,1000); > > Common sense, which tells me not to do such things, is a welcome ally. Certainly, but if I have been following this correctly, the 1000 is a red herring which casts doubt on the programmers ability. f.e., what if some rogue process (or kernel!) manages to increase that files size to 680 bytes? The last argument to read is your friend. :-) If you know your file will be always 68 bytes, then put 68 there. Even better, as I assume you are putting in the 1000 as a catchall for expansion, put a #define in, and base the size of your buffer, and the last argument to read on that. Simple and effective. What Robert is complaining about is that he is reading a 68 byte file by requesting 1000 bytes; and that in his opinion, read should stop reading at the end of the file, and return control. Myself, I would see this auto-stop idea as a _feature_ of read(). features can only be relied upon portably if they are positively documented in POSIX. This feature is not therefore portable, as POSIX is muddy on the matter. I suppose in c.l.c speak, it would be called `implementation-defined'. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. If you keep saying things are going to be bad, you have a chance of being a prophet. -- Isaac Bashevis Singer ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley @ 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-11 0:00 ` Robert Dewar 1 sibling, 2 replies; 177+ messages in thread From: Robert A Duff @ 1996-04-11 0:00 UTC (permalink / raw) In article <829194658snz@tsys.demon.co.uk>, Tom Wheeley <tomw@tsys.demon.co.uk> wrote: >What Robert is complaining about is that he is reading a 68 byte file by >requesting 1000 bytes; and that in his opinion, read should stop reading >at the end of the file, and return control. No, I think Robert is complaining (quite correctly) that the documentation is unclear on this point. You shouldn't have to rely on common sense to know what 'read' does in various error cases, or to know which cases are in fact considered errors. The problem is that everybody's common sense doesn't match everybody else's, at least not in all cases. >Myself, I would see this auto-stop idea as a _feature_ of read(). features >can only be relied upon portably if they are positively documented in POSIX. >This feature is not therefore portable, as POSIX is muddy on the matter. > >I suppose in c.l.c speak, it would be called `implementation-defined'. If POSIX wants to make it implementation defined, or undefined, or whatever, then it should say so explicitly. Making something undefined by forgetting to define it is bad style. - Bob ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert A Duff @ 1996-04-12 0:00 ` Tom Wheeley 1996-04-12 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 1 reply; 177+ messages in thread From: Tom Wheeley @ 1996-04-12 0:00 UTC (permalink / raw) In article <DppsHq.1Ar@world.std.com> bobduff@world.std.com "Robert A Duff" writes: > > >Myself, I would see this auto-stop idea as a _feature_ of read(). features > >can only be relied upon portably if they are positively documented in POSIX. > >This feature is not therefore portable, as POSIX is muddy on the matter. > > > >I suppose in c.l.c speak, it would be called `implementation-defined'. > > If POSIX wants to make it implementation defined, or undefined, or > whatever, then it should say so explicitly. Making something undefined > by forgetting to define it is bad style. I didn't say it was right, I just said that's how it is. Although it seems that POSIX falls short of what is desired by many people, you cannot expect it to specify the definition for every possible case. As a programmer, you should know what to do if the spec does fall short, and that is to be conservative with what you give out, and liberal in what you receive; in the spirit of RFCs. imho, expecting read() to stop at the end of the file, despite asking it to read 1000 bytes is being liberal with what you give out. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. "I'm a paranoid agnostic. I doubt the existence of God, but I'm sure there is some force, somewhere, working against me." --Marc Maron ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Tom Wheeley @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Tom said "imho, expecting read() to stop at the end of the file, despite asking it to read 1000 bytes is being liberal with what you give out." No doubt about that, but always remember that it is trivial to write portable code in any language if you have the capability of making 100% sure that you only use portable constructs! Unfortunately, almost no large project I have seen has this capability. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829346082@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >No doubt about that, but always remember that it is trivial to write >portable code in any language if you have the capability of making >100% sure that you only use portable constructs! Unfortunately, almost >no large project I have seen has this capability. If the project managers want to use software standards to help ensure portability, there's no barrier I'm aware of that keeps them from using standard semantics for the system-independent parts of their projects. In many cases this greatly reduces porting effort for most of the source. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) "If the project managers want to use software standards to help ensure portability, there's no barrier I'm aware of that keeps them from using standard semantics for the system-independent parts of their projects. In many cases this greatly reduces porting effort for most of the source." I completely agree with Chuck Karish on this. Clear specifications from appropriate software standards, which are well understaood and carefully followed by all programmers, without reference to "unwritten rules" and "sensible reasoning", are a huge help in making programs easily portable. If anyone can remember back far enough :-) this is the point that I was originally making with respect to the read function! Note however that this is not sufficient to guarantee portability. For simple programs that can be made 100% portable, then indeed carefully following standards is a key. In this regard, I far prefer national and international standards to industry standards, since the former have typically gone through a much more intensive review, and are more stable (I preer that ISO owns a standard and is the only one who can change it, than that the standard be owned by the "current holder of the copyright", whose interests are fundamentally commercial ones which may even be at odds with the basic goals of standardization). However, many large programs have sections that cannot be written in a portable manner, and here the issue is very careful isolation and documentation of these sections of code. In my experience many portability problems are caused by programmers not understanding the relevant standards well. How many C++ programmers have read the proposed draft standard. FOr that matter how many C programmers have read the ANSI standard for C. One problem is that these standards are often remarkably inaccessible, and/or expensive. It certainly would be nice if other languages and systems could follow the lead of Ada, and make their standards freely available over the net. The POSIX standard has, at least in the past, been problematical from this point of view. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery ` (2 more replies) 0 siblings, 3 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Saturday, April 13, 1996, Robert Dewar wrote... > "If the project managers want to use software standards to help > ensure portability, there's no barrier I'm aware of that keeps > them from using standard semantics for the system-independent > parts of their projects. In many cases this greatly reduces > porting effort for most of the source." > > I completely agree with Chuck Karish on this. Clear specifications from > appropriate software standards, which are well understaood and carefully > followed by all programmers, without reference to "unwritten rules" > and "sensible reasoning", are a huge help in making programs easily > portable. If anyone can remember back far enough :-) this is the point > that I was originally making with respect to the read function! > > Note however that this is not sufficient to guarantee portability. For > simple programs that can be made 100% portable, then indeed carefully > following standards is a key. In this regard, I far prefer national > and international standards to industry standards, since the former > have typically gone through a much more intensive review, and are > more stable (I preer that ISO owns a standard and is the only one > who can change it, than that the standard be owned by the "current > holder of the copyright", whose interests are fundamentally commercial > ones which may even be at odds with the basic goals of standardization). > > However, many large programs have sections that cannot be written > in a portable manner, and here the issue is very careful isolation > and documentation of these sections of code. > > In my experience many portability problems are caused by programmers > not understanding the relevant standards well. How many C++ programmers > have read the proposed draft standard. FOr that matter how many C > programmers have read the ANSI standard for C. One problem is that > these standards are often remarkably inaccessible, and/or expensive. > It certainly would be nice if other languages and systems could follow > the lead of Ada, and make their standards freely available over the net. > The POSIX standard has, at least in the past, been problematical from > this point of view. > > The standards are a lot more accessible now with the increased popularity of the Internet. I've read both standards, and the bigger problem is the inaccessible legalese of the standards themselves, which are written for compiler vendors, *not* programmers. Pick up Schildt's "Annoted ANSI C Standard" and Plauger/Brodie's "Standard C: A Reference". Between the two they cover the original standard and Amendment 1 fairly well. You can get the April 1995 C++ papers from AT&T's Web site in PostScript format, and from several other sites in HTML. Other sites typically have the (confidential) September 1995 papers. You can find them fairly easily with Infoseek: [C++ standard] ANSI ISO Bradd ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Keith Thompson 2 siblings, 0 replies; 177+ messages in thread From: David Emery @ 1996-04-19 0:00 UTC (permalink / raw) People who have read both documents have told me that the POSIX.5 standard is substantially more readable/usable than the POSIX.1 standard. (-I- certainly think so, but my opinion is biased in this area.) Before anyone asserts "standards are unreadable", I suggest that they look at something more than the current batch of C standards, which set a mediocre example, IMHO. dave ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery @ 1996-04-19 0:00 ` Robert Dewar 1996-04-22 0:00 ` Peter Seebach 1996-04-23 0:00 ` Keith Thompson 2 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) Bradd said "The standards are a lot more accessible now with the increased popularity of the Internet. I've read both standards, and the bigger problem is the inaccessible legalese of the standards themselves, which are written for compiler vendors, *not* programmers." Any programmer who cannot read an informally written standard like the ANSI C standard has in my view a serious lack of capability in understanding written specifications. These standards are definitely written for programmers, and any competent programmer should be able to read them once they have a reasonable introduction (I am not claiming that tpyical programmers can learn a language from the standard). By informally written here, I am making a contrast with a formal standard, written in formal mathematical style, which can indeed be somewhat inaccessible to programmers not well trained in mathematics. P.S. Who do you think reads these documents at "compiler vendors". I will let you in on a secret: the answer is "programmers"! ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-22 0:00 ` Peter Seebach 0 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-22 0:00 UTC (permalink / raw) In article <dewar.829970326@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Any programmer who cannot read an informally written standard like the >ANSI C standard has in my view a serious lack of capability in understanding >written specifications. These standards are definitely written for >programmers, and any competent programmer should be able to read them >once they have a reasonable introduction (I am not claiming that tpyical >programmers can learn a language from the standard). Hey, everybody, look, Dewar and I agree on something! I made one attempt at learning C++ from some sort of introductory text. It was hopeless. I learned what of it I know by reading the _Annotated Reference Manual_, which was quite legible. >By informally written here, I am making a contrast with a formal >standard, written in formal mathematical style, which can indeed >be somewhat inaccessible to programmers not well trained in >mathematics. I am of the opinion that most mathematical texts are poorly written, because used English can be precise enough for much of what they want to say. I find it offensive that textbooks use little squiggly bits when the equivalent sentence would hae been just as precise. On the other hand, I'm a great fan of chatty proofs, so take this with a grain of salt. >P.S. Who do you think reads these documents at "compiler vendors". I will >let you in on a secret: the answer is "programmers"! You have obviously never used a C compiler. It is quite clear that the people writing them are communicating with the people reading the standard through interoffice mail. :) "Hmm. Does 'shall' mean you do it or you don't do it?" -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Keith Thompson 2 siblings, 0 replies; 177+ messages in thread From: Keith Thompson @ 1996-04-23 0:00 UTC (permalink / raw) In <01bb2dd0.a8395e00$c6c2b7c7@Zany.localhost> Bradd W. Szonye <bradds@ix.netcom.com> writes: > Pick up Schildt's "Annoted ANSI C Standard" and Plauger/Brodie's "Standard > C: A Reference". Between the two they cover the original standard and > Amendment 1 fairly well. For a good critique of Schildt's "Annoted ANSI C Standard", see <http://www.lysator.liu.se/c/schildt.html>. Quick summary: if you ignore the annotations, it's a good way to get a copy (nearly) of the standard. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-19 0:00 ` Robert A Duff 1 sibling, 2 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Thursday, April 11, 1996, Robert A Duff wrote... > In article <829194658snz@tsys.demon.co.uk>, > Tom Wheeley <tomw@tsys.demon.co.uk> wrote: > >What Robert is complaining about is that he is reading a 68 byte file by > >requesting 1000 bytes; and that in his opinion, read should stop reading > >at the end of the file, and return control. > > No, I think Robert is complaining (quite correctly) that the > documentation is unclear on this point. You shouldn't have to rely on > common sense to know what 'read' does in various error cases, or to know > which cases are in fact considered errors. The problem is that > everybody's common sense doesn't match everybody else's, at least not in > all cases. Pardon me if this sounds silly, but... You shouldn't have to rely on the documentation to make up for a lack of common sense. Bradd. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert A Duff 1 sibling, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) iBradd said "Pardon me if this sounds silly, but... You shouldn't have to rely on the documentation to make up for a lack of common sense. Bradd." The idea that common sense can replace specifications is truly ludicrous. So ludicrous in fact that this must be a late April fool;s joke, no one could seriously write the above :-) ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert Dewar wrote... > iBradd said > > "Pardon me if this sounds silly, but... > You shouldn't have to rely on the documentation to make up for a lack of > common sense. > > Bradd." > > The idea that common sense can replace specifications is truly ludicrous. > So ludicrous in fact that this must be a late April fool;s joke, no one > could seriously write the above :-) Ha! I now envision rooms full of programmers, each provided with up-to-the-minute paper and on-line versions of every applicable standard but with their common sense nerve centers surgically removed. Wait! That sounds like some programmers I know... -- Bradd W. Szonye (bradds@ix.netcom.com), Doubleplus Corporation "To chill or to pop a cap in my dome, whoomp, there it is." -- Hamlet, Prince of Denmark ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Robert A Duff 1996-04-20 0:00 ` Bradd W. Szonye 1 sibling, 1 reply; 177+ messages in thread From: Robert A Duff @ 1996-04-19 0:00 UTC (permalink / raw) In article <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost>, Bradd W. Szonye <bradds@ix.netcom.com> wrote: >Pardon me if this sounds silly, but... >You shouldn't have to rely on the documentation to make up for a lack of >common sense. Well, sorry, but it *does* sound pretty silly, to me. Anybody who's been around computer software for a while knows pretty well that predicting what software does from some vague notion of "common sense" is impossible. For example, common sense might tell you that function arguments are evaluated from left to right. Not true in C, not true in Ada, not true in C++ (there, I made it relevant to all these newsgroups, in case anyone's still listening ;-) ). These languages all go *against* common sense (for obscure efficiency reasons, of course). In this case, if you rely on common sense, instead of reading the language standard, you'll get into deep trouble. - Bob ^ permalink raw reply [flat|nested] 177+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert A Duff @ 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 177+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert A Duff wrote... > In article <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost>, > Bradd W. Szonye <bradds@ix.netcom.com> wrote: > >Pardon me if this sounds silly, but... > >You shouldn't have to rely on the documentation to make up for a lack of > >common sense. > > Well, sorry, but it *does* sound pretty silly, to me. Anybody who's > been around computer software for a while knows pretty well that > predicting what software does from some vague notion of "common sense" > is impossible. > > For example, common sense might tell you that function arguments are > evaluated from left to right. Not true in C, not true in Ada, not true > in C++ (there, I made it relevant to all these newsgroups, in case > anyone's still listening ;-) ). These languages all go *against* common > sense (for obscure efficiency reasons, of course). In this case, if you > rely on common sense, instead of reading the language standard, you'll > get into deep trouble. > > - Bob I don't let documents substitute for common sense. That doesn't mean I *ignore* the documentation; that would non-sensical too. Part of common sense is experience. Experience tells you that arguments get pushed (not evaluated) right-to-left. Experience tells you you can't count on what order C evaluates function arguments at all. Experience tells you that if you claim that a buffer is 1000 bytes long, it should be 1000 bytes long, even if the standard *explicitly* says that it's okay to do otherwise under certain circumstances. In general, you shouldn't use every nitpicky detail of what is and isn't legal according to the standard. Not all compilers are conformant, even if they claim to be. Compiler vendors make mistakes too, and frequently your only guarantee that a compiler is 100% conformant is the vendor's assurance that it is. I know programmers who will look up (or have memorized) the operator precedence rules in C. These programmers will always use the minimal number of parentheses in an expression because they know the rules precisely. Not everyone does; maintenance programmers in particular tend to be junior programmers who don't know all the rules. A maintenance programmer is likely to "fix" something that looks wrong, even if it isn't. And a maintenance programmer is likely to misinterpret some subtle detail of a standard that the original programmer had to look up in the first place. My personal rule: if you have to look it up to make sure you're absolutely right, your code may not be maintainable or portable. If you can do it without looking it up; if it's absolutely as clear as the nose on your face, then it's okay. For more on this, read "Writing Solid Code" by Steve Maguire (Microsoft Press). ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert A Duff @ 1996-04-11 0:00 ` Robert Dewar 1 sibling, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) "What Robert is complaining about is that he is reading a 68 byte file by requesting 1000 bytes; and that in his opinion, read should stop reading at the end of the file, and return control." First of all, this is not Robert's code, he has not written in C for a while. Second, Robert does not particularly have an opinion about what read should or should not do! Robert was only pointing this out as an example of non-portability caused by sloppy specifications. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987544@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Can you quote the relevant standard. No description of read I ever saw >was detailed or precise enough to say what the requirements on the caller >are. If it is not specified, it's undefined. At least, that's how C does it; no guarantees for POSIX. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) I said >>Can you quote the relevant standard. No description of read I ever saw >>was detailed or precise enough to say what the requirements on the caller >>are. Peter said >If it is not specified, it's undefined. At least, that's how C does it; >no guarantees for POSIX. Robert replies OK, "it" here is any specification of how long the buffer should be. So Peter considers it undefined, in which case *any* call to read is undefined. Actually I completely agree, if the spec of a routine is incomplete or imprecise, the routine cannot be called without generating undefined behavior. But in the absence of Kazimir to tell us the "unwritten" rules, isn't it just possible that this *might* lead to portability problems :-) Of course by Peter's rules, we can't call read at all :-) Peter do you have SPEC1170, I assume you must have a copy, so can you see there if the spec is any more illuminating? ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829054330@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >OK, "it" here is any specification of how long the buffer should be. So >Peter considers it undefined, in which case *any* call to read is >undefined. Actually I completely agree, if the spec of a routine is >incomplete or imprecise, the routine cannot be called without generating >undefined behavior. Well, read() can't be called in C. Assuming POSIX, the behavior is clearly defined, but no specification is made of which if any boundaries are checked; thus, the only safe thing to do is comply with all of them reliably. >But in the absence of Kazimir to tell us the "unwritten" rules, isn't it >just possible that this *might* lead to portability problems :-) Of course >by Peter's rules, we can't call read at all :-) Not in C. My rule would be that if a function does not say something is safe, you shouldn't do it. The normal descriptions of read() (I've read dozens, and they're all pretty much equivalent) describe the behavior in terms of a buffer having enough space to hold nbytes of data. >Peter do you have SPEC1170, I assume you must have a copy, so can you >see there if the spec is any more illuminating? No, I don't have a copy. Spec 1170 is nearly as expensive as ANSI, and I get expensive specs only once or twice a year. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829054330@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >I said > >>>Can you quote the relevant standard. No description of read I ever saw >>>was detailed or precise enough to say what the requirements on the caller >>>are. > >Peter said > >>If it is not specified, it's undefined. At least, that's how C does it; >>no guarantees for POSIX. > >Robert replies > >OK, "it" here is any specification of how long the buffer should be. So >Peter considers it undefined, in which case *any* call to read is >undefined. Actually I completely agree, if the spec of a routine is >incomplete or imprecise, the routine cannot be called without generating >undefined behavior. > >But in the absence of Kazimir to tell us the "unwritten" rules, isn't it >just possible that this *might* lead to portability problems :-) Of course >by Peter's rules, we can't call read at all :-) No, the _rational_ rules. I slipped up in my mention of ``unwritten rules'' because in this case they happen to coincide with the rational ``Bayesian'' choice. In other cases, as in the case of select(), they may not. I did not mean to imply that I would not falsely advertize a buffer to read() simply because I feel that there is an unwritten rule among a community of programmers which prohibits this. I would not do this due to a reasoning process, which may come up with an answer that is different from the concensus. A later clarification in the standard, and subsequent compliance by all implementations, may render my assumption paranoid, but until then the rational choice gives a fighting chance that the program will work and be portable. I recognize that there are cases where such reasoning may fail to achieve a resolution. In the Pascal table, you may have a "you are screwed" in each row and column, in which case you must consider additional alternatives. >Peter do you have SPEC1170, I assume you must have a copy, so can you >see there if the spec is any more illuminating? That would be helpful. --- A good friend of mine says: you can spot a programmer in a one way street---he is the one who looks both ways before crossing. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku ` (2 more replies) 2 siblings, 3 replies; 177+ messages in thread From: Robert I. Eachus @ 1996-04-09 0:00 UTC (permalink / raw) I hope that everyone following this thread knows that this "undefined" behavior lead to one of the security holes exploited by the Morris Internet worm. Undefined only means unusable in some contexts, and if the C read had a way to know the size of the buffer passed, that particular security hole would not have existed. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 177+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <EACHUS.96Apr9184019@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: > > I hope that everyone following this thread knows that this >"undefined" behavior lead to one of the security holes exploited by >the Morris Internet worm. No, this was something to do with gets being applied to an automatic buffer. If you picture the downward growing stack on a Sun3 or VAX, imagine what you can do if you can overrun a stack array variable with bytes that spell out machine code. If you are clever, you can overwrite the buffer in such a way that the return address on the stack is modified to jump to the other portions of your array. This can be done thanks to absolute addressing on a machine with virtual address spaces, where each process always starts out with the same stack pointer value. Once you jump to your array, you have control of the machine. You can do system calls galore---and if you are running under euid 0, you are God. I should try this under Linux just for fun. The POSIX.1 standard was not even around then, by the way. > Undefined only means unusable in some contexts, and if the C read >had a way to know the size of the buffer passed, that particular >security hole would not have existed. That much is true, modulo s/read/gets/ The read function has a way to know the buffer size, namely the nbytes argument. (There is no read in C, by the way) The gets() function has no such argument and should be avoided like the plague except in totally trivial, makeshift programs or in debugging. There are still some old-timer bugs that plague (commercial) UNIX: try typing a !%s%s%s%s command to the C shell (not tcsh, but the more crappy real one that you actually _pay_ for when you buy a SVR4 unix). It tries to tell you that the %s%s%s%s event is not found in the history. But guess what? It uses raw printf(), so the %s's get interpreted as format strings. The function looks for non-existent arguments, resulting in strange behavior, like crap being printed on the terminal. -- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <EACHUS.96Apr9184019@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: > I hope that everyone following this thread knows that this >"undefined" behavior lead to one of the security holes exploited by >the Morris Internet worm. No, it quite definitely isn't. The worm mostly used the function gets(). > Undefined only means unusable in some contexts, and if the C read >had a way to know the size of the buffer passed, that particular >security hole would not have existed. C does not have a read() function. read() is a feature of Unix or POSIX-like systems. The worm bug had nothing to do with the vague semantics of read. (I've talked about this with Robert. I still believe the code was incorrect, and he does not deny this, but I would have to say that he's right - the standard should be explicit about the requirements of read(), and the C standard should likewise be specific about the requirements of the buffer passed to fgets(), et al.) The bug that caused the worm to be dangerous was that gets() has no way of determining that there are buffer problems. Good implementations will give you a diagnostic message if you use gets(). (Well, NetBSD does.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach @ 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 177+ messages in thread From: BLUE @ 1996-04-25 0:00 UTC (permalink / raw) In ar ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 3 siblings, 0 replies; 177+ messages in thread From: Tom Payne @ 1996-04-10 0:00 UTC (permalink / raw) Matt Austern (austern@isolde.mti.sgi.com) wrote: : In article <4kgmgu$jm@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes: : : > The problem shows up in real situations: In C++ AFAIK there is no : > efficient way for an exception at the hardware level to generate an : > exception (in the C++ sense) on the part of the running program -- the : > running must poll a volatile atomic variable to see if the exception : > has occurred. This obviously makes the langauge, as defined in the : > standard, unacceptable for use in the area of, say, embedded systems. : > Even in scientific progrmming, however, one would like to be able to : > throw an exception out of a matrix manipulation routine when the : > underlying hardware detects a floating point exception, and polling : > for such an occurrence would involve unacceptable overhead. : : Are you sure that this is possible on the machines that you'd like : your program to run on? On many of today's RISC chips, after all, : floating point exceptions are asynchronous: you have no way of : knowing which instruction caused the problem. : : (This sounds perverse, but there's a reason for it. If you want : synchronous exceptions, you end up having to stall the pipeline when : you're processing a floating point instruction.) The scientific programming community has bad to put up with imprecise detection of floating point exceptions since the IBM 360/91, or before. I'm not asking that a C/C++ implementation do anything more than pass the information along (via a signal) when it gets it. (That's why I said " ... when the underlying hardware detects a floating point exception ...".) The problem, however, is not the timing of the resulting signal, but what I can (and can't) do within its handler. The handler cannot read global data and, hence, cannot take any kind of corrective action. Also, it cannot throw an exception to unwind the computation back to some known state. Other than aborting the computation, the only option left to a C/C++ signal handler is to set a flag that the program must poll to determine that a floating-point exception has occurred and to take corrective action such as throwing a C++ exception. I don't know Ada, but I doubt that it suffers the same limitation, and I expect that Gnat implements Ada on virtually all machines that run C/C++. (To that extent, I am moderately sure that what I'm asking for is doable.) Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1996-04-10 0:00 ` Tom Payne @ 1996-04-10 0:00 ` Matt Austern 1996-04-10 0:00 ` Robert Dewar 3 siblings, 1 reply; 177+ messages in thread From: Matt Austern @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgmgu$jm@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes: > The problem shows up in real situations: In C++ AFAIK there is no > efficient way for an exception at the hardware level to generate an > exception (in the C++ sense) on the part of the running program -- the > running must poll a volatile atomic variable to see if the exception > has occurred. This obviously makes the langauge, as defined in the > standard, unacceptable for use in the area of, say, embedded systems. > Even in scientific progrmming, however, one would like to be able to > throw an exception out of a matrix manipulation routine when the > underlying hardware detects a floating point exception, and polling > for such an occurrence would involve unacceptable overhead. Are you sure that this is possible on the machines that you'd like your program to run on? On many of today's RISC chips, after all, floating point exceptions are asynchronous: you have no way of knowing which instruction caused the problem. (This sounds perverse, but there's a reason for it. If you want synchronous exceptions, you end up having to stall the pipeline when you're processing a floating point instruction.) -- Matt Austern SGI: MTI Compilers Group austern@isolde.mti.sgi.com ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Matt Austern @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) "Are you sure that this is possible on the machines that you'd like your program to run on? On many of today's RISC chips, after all, floating point exceptions are asynchronous: you have no way of knowing which instruction caused the problem." Actually, some modern RISC chips effectively do not generate floating-point exceptions. The IEEE 754 (floating-point) standard does NOT require this capability. An example is the POWER architecture, where you can only get floating-point exceptions by disconnecting the pipeline and slowing down ALL code drastically. This mode is intended only or debugging, not for production use. It seems quite reasonable in fact to consider designing floating-point feature sets with no capability of asyncrhonous exceptions at all. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach @ 1996-04-07 0:00 ` Lawrence Kirby 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Dan Pop 2 siblings, 1 reply; 177+ messages in thread From: Lawrence Kirby @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828879781@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Dan Pop > >"This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI >compliant for the simple reason that the ANSI/ISO C standard does NOT >define such a function. read may (or may not) be POSIX, SVID or XPG >" > >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. If that was the point, it is about the most pointless one I've seen! :-) >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). You do have a point there. However ANSI does have a few things to say about the identifier read. It is not reserved which means I can define my own external linkage function called read in a strictly conforming C program. If this doesn't work correctly on a POSIX system then it isn't ANSI conforming. So particular implementations of read() may not be ANSI conforming. Also if, say, fread() went and called my read() instead of the system one that would also fail to be conforming. Implementations generally need to pull a few tricks to make sure this all works correctly. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-07 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 0 siblings, 1 reply; 177+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) "No, they call themselves Unix. They *cannot* call themselves UNIX(tm)." This surely must be wrong, either Unix is a trade mark or it is not. If it is, then the whole point of a trademark is that it stops people from using it without your permission, or without appropriate acknowledgement. In fact from what Dan Pop says, systems like Solaris and Irix *can* in fact call themselves Unix, since they have an appropaite agreement with the trademark holder. What is not clear is what is involved (other than paying a fee) in getting this permission (i.e. is there any formal testing process?) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 0 siblings, 1 reply; 177+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828912460@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >This surely must be wrong, either Unix is a trade mark or it is not. Consider: Wednesday(TM) is a small, homicidal girl with long hair. Wednesday is two days from when I write this. UNIX is a trademark. Unix is not really. Rather, the X/Open people have decided to allow things similar to Unix to be called "Unix systems", but not to use the little (tm) symbol. >In fact from what Dan Pop says, systems like Solaris and Irix *can* in >fact call themselves Unix, since they have an appropaite agreement with >the trademark holder. What is not clear is what is involved (other than >paying a fee) in getting this permission (i.e. is there any formal >testing process?) Assumably, there is, because they had to alter their systems to get that approval, though not much, because SVR4 out of the box is pretty much canonical Unix, and Solaris is definitely an SVR4 derivitive. (It has the SVR2-4 sed bug.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Dan Pop 0 siblings, 2 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter Seebach says "Assumably, there is [a formal set of testing procedures for Unix compliance]" I never heard of such a set of tests, but of course they could still well exist! But "assumably" [entertaining portmanteau word :-)] is not good enough to answer this. Doesn't *anyone* know anything about the procedures here. Peter Seebach's claims about trademarks are most peculiar, certainly not even vaguely correct in the US (where you could never manage to trademark Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Dan Pop 1 sibling, 0 replies; 177+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987795@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter Seebach's claims about trademarks are most peculiar, certainly not >even vaguely correct in the US (where you could never manage to trademark >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) Tell that to the people who did the Addams Family movie. I used to still have a piece of packaging from some thing that referred to "Wednesday[tm]", and explained that Wednesday was a trade mark of their studio. Commodore trademarked "3000T". Heh. Now, trademarks that would *hold up in court*, maybe not; but our society is too strange to worry about. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Dan Pop 1996-04-09 0:00 ` James McIninch 1 sibling, 1 reply; 177+ messages in thread From: Dan Pop @ 1996-04-09 0:00 UTC (permalink / raw) In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Peter Seebach's claims about trademarks are most peculiar, certainly not >even vaguely correct in the US (where you could never manage to trademark >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) If someone managed to trademark Apple, I see no reason why one couldn't trademark Wednesday in the US. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Dan Pop @ 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop 1996-04-11 0:00 ` Tom Wheeley 0 siblings, 2 replies; 177+ messages in thread From: James McIninch @ 1996-04-09 0:00 UTC (permalink / raw) Dan Pop (danpop@mail.cern.ch) wrote: : In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: : >Peter Seebach's claims about trademarks are most peculiar, certainly not : >even vaguely correct in the US (where you could never manage to trademark : >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) : If someone managed to trademark Apple, I see no reason why one couldn't : trademark Wednesday in the US. It's important to note that US trademark law recognizes certain tiers of protection for trademarks, of which trademarking a common word is the weakest form of protected trademark. The strongest trademark is where you invent a name and trademark it, a name that doesn't resemble any word: like Arco or Quisp. The only way you could be conceivably guilty of infringing on Apple's trade- mark (which is 'Apple Computer'), is by using it as the name of a computer company of some sort. If you started a company called 'Apple Consulting', that would be okay. If you started a company called 'Apple Computer Consulting', you'll probably hear from a lawyer. ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` James McIninch @ 1996-04-10 0:00 ` Dan Pop 1996-04-09 0:00 ` Danette & Murray Root 1996-04-11 0:00 ` Tom Wheeley 1 sibling, 1 reply; 177+ messages in thread From: Dan Pop @ 1996-04-10 0:00 UTC (permalink / raw) In <4keoed$bur@mordred.gatech.edu> james@amber.biology.gatech.edu (James McIninch) writes: >Dan Pop (danpop@mail.cern.ch) wrote: >: In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > >: >Peter Seebach's claims about trademarks are most peculiar, certainly not >: >even vaguely correct in the US (where you could never manage to trademark >: >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) > >: If someone managed to trademark Apple, I see no reason why one couldn't >: trademark Wednesday in the US. > >The only way you could be conceivably guilty of infringing on Apple's trade- >mark (which is 'Apple Computer'), is by using it as the name of a computer >company of some sort. If you started a company called 'Apple Consulting', that >would be okay. If you started a company called 'Apple Computer Consulting', >you'll probably hear from a lawyer. A couple of questions: 1. What if I start a company named "Foobar" manufacturing a computer named "Apple"? Am I going to have troubles or not? 2. What if I start a company named "Wednesday Computer" manufacturing a computer named "Wednesday"? Am I going to be protected by the US trademark law or not? Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Dan Pop @ 1996-04-09 0:00 ` Danette & Murray Root 0 siblings, 0 replies; 177+ messages in thread From: Danette & Murray Root @ 1996-04-09 0:00 UTC (permalink / raw) Dan Pop wrote: > ----[snip]---- > > A couple of questions: > > 1. What if I start a company named "Foobar" manufacturing a computer > named "Apple"? Am I going to have troubles or not? Yes. Apple HAS trademarked 'Apple' as a computer name brand. They could (and probably would) sue your pants off. > 2. What if I start a company named "Wednesday Computer" manufacturing > a computer named "Wednesday"? Am I going to be protected by the > US trademark law or not? You would be safe IF and ONLY IF no person, corporation, or company has trademarked 'Wednesday' as a brand name for a computer company or computing equipment. It's trademark for a movie character, action figure, toy, etc. would NOT apply. And a trademark is only valid if it is USED (reserving a trademark has a very short legal duration) in the context under question. [Note: I am not a lawyer. This information does NOT constitute legal advice. For legal advice consult a shyster - ahem - lawyer.] ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop @ 1996-04-11 0:00 ` Tom Wheeley 1 sibling, 0 replies; 177+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <4keoed$bur@mordred.gatech.edu> james@amber.biology.gatech.edu "James McIninch" writes: > Dan Pop (danpop@mail.cern.ch) wrote: > : In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > > : >Peter Seebach's claims about trademarks are most peculiar, certainly not > : >even vaguely correct in the US (where you could never manage to trademark > : >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!)> > : If someone managed to trademark Apple, I see no reason why one couldn't > : trademark Wednesday in the US. > > The only way you could be conceivably guilty of infringing on Apple's trade- > mark (which is 'Apple Computer'), is by using it as the name of a computer > company of some sort. If you started a company called 'Apple Consulting', that > would be okay. If you started a company called 'Apple Computer Consulting', > you'll probably hear from a lawyer. Incidentally, Apple records had the `Apple' trademark first, and Apple Computer were only allowed to use the name, as long as they didn't diverge into sound recording of any sort. Now that Apple make multimedia machines, Apple records could have a case... .splitbung -- * TQ 1.0 * The 'Just So Quotes'. Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-07 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 2 siblings, 1 reply; 177+ messages in thread From: Dan Pop @ 1996-04-07 0:00 UTC (permalink / raw) In <dewar.828879781@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Dan Pop > >"This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI >compliant for the simple reason that the ANSI/ISO C standard does NOT >define such a function. read may (or may not) be POSIX, SVID or XPG >" > >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. > >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). A program calling a function which isn't defined by that program and isn't part of the standard C library invokes undefined behaviour (the same as dereferencing a null pointing or dividing by zero). Such a program is not a strictly conforming ANSI C program. >It would be interesting to know more details about Unix validation. I >guess the point here is that most systems that people think of as Unix >are actually NOT called Unix (e.g. Linux, IRIX, AIX, Solaris), and so >you have to be very careful in understanding what this validation means. It's not a matter of how they are called, but of what they claim to be. For example, Solaris claims to be: UNIX(r) System V Release 4.0 and IRIX says: IRIX System V.4 >I guess the issue here is IPR protection rather than propagation of an >open standard. > >Precisely which commonly used Unix-like systems have been certified by >the copyright holder in this manner? Solaris and IRIX, by the time the copyright holder was Novell, Digital UNIX by X/Open. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 177+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Dan Pop @ 1996-04-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 177+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) If Solaris and IRIX are both certified to meet some Unix standard, it must be a very weak one, because these two systems are HIGHLY incompatible with one another at the level which I would associate with certification. Different sets of routines are supported, and the semantics of similar routines (e.g. thread-safeness) differs. The threads packages are quite different, the make utilities are quite incompatible etc. etc. If the Unix validation correspondes to a set of test programs, then they must be very weak. I wonder if there are any technical teeth at all in this validation process, or whether it is an essentially beuarocratic check-off process. Can someone familiar with the process give some idea of whether indeed it corresponds to validation or certification procedures in the e.g. NIST sense. Regarding read being non-ANSI, to me the fact that a program uses thir party libraries whether or not they are written in C (or ANSI-C for that matter) does not make the progam a non-conforming program. I don' t see that at all. If that were the case, then virtually no programs are conforming (since they use, for example, graphics libraries), so the concept of conformance is not very useful. Anyway this is just semantics really, when I said that I did not consider the read in Linux to violate the ANSI standard, I was precisely meaning that the standard has nothing to say here. So I think Dan and I agre, read is not defined by th ANSI standard, therefore the ANSI standard has nothing to say on the issue of whether the unusual semantics of read in Linux are are not "correct", whatever that might mean. ^ permalink raw reply [flat|nested] 177+ messages in thread
end of thread, other threads:[~1996-04-25 0:00 UTC | newest] Thread overview: 177+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-04-12 0:00 ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Chuck Karish 1996-04-11 0:00 ` Robert Dewar 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Mike Rubenstein 1996-04-22 0:00 ` Tom Payne 1996-04-22 0:00 ` Peter Seebach [not found] <JSA.96Feb16135027@organon.com> 1996-03-26 0:00 ` C/C++ knocks the crap out of Ada Ed Falis 1996-03-28 0:00 ` Kevin Cline 1996-03-30 0:00 ` Jon S Anthony 1996-04-01 0:00 ` Kevin Cline 1996-04-02 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton 1996-04-03 0:00 ` David Emery 1996-04-03 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Dan Pop 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` David Emery 1996-04-06 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 1996-04-16 0:00 ` Robert Dewar 1996-04-19 0:00 ` Chuck Karish 1996-04-05 0:00 ` Peter Seebach 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Robert Dewar 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 1996-04-22 0:00 ` Mike McCarty 1996-04-22 0:00 ` David Emery 1996-04-06 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Fergus Henderson 1996-04-10 0:00 ` Tom Payne 1996-04-09 0:00 ` Robert Dewar 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Steve Summit 1996-04-10 0:00 ` Robert Dewar 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Lawrence Kirby 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` David Emery 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` John Marshall 1996-04-10 0:00 ` Robert Dewar 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Dr S.J. Harris 1996-04-12 0:00 ` Peter Seebach 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Gareth Rees 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-20 0:00 ` Fergus Henderson 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar 1996-04-22 0:00 ` Peter Seebach 1996-04-23 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert A Duff 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-11 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 1996-04-10 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-07 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Dan Pop 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop 1996-04-09 0:00 ` Danette & Murray Root 1996-04-11 0:00 ` Tom Wheeley 1996-04-07 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox