From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: scs@eskimo.com (Steve Summit) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: X-Deja-AN: 146783743 sender: news@eskimo.com (News User Id) x-nntp-posting-host: eskimo.com references: <828964950snz@genesis.demon.co.uk> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> followup-to: comp.lang.ada,comp.lang.c,comp.lang.c++ organization: schmorganization newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: [followups trimmed, and should probably be trimmed further] In article , 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