Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!mit-eddie!snorkelwacker.mit.edu!bloom-picayune.mit.edu!adam!scs From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Changes to Answers to Frequently Asked Questions (FAQ) on comp.lang.c Message-ID: <1991Feb6.070148.1901@athena.mit.edu> Date: 6 Feb 91 07:01:48 GMT Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu (Steve Summit) Organization: Thermal Technologies, Inc. Lines: 199 This article contains changes between the previous posting of the frequently-asked questions list (posted January 1) and the new one. (Do _not_ worry if you have not seen the new one yet; it's coming up next.) (These diffs have been edited for readability and are not suitable for the patch program.) By the way, sorry for the delay in this month's FAQ postings: I was busy traveling and getting engaged. ========== < [Last modified December 16, 1990 by scs.] --- > [Last modified February 5, 1990 by scs.] ========== > 18. I came across some "joke" code containing the "expression" > 5["abcdef"] . How can this be legal C? > > A: Yes, Virginia, array subscripting is commutative in C. This curious > fact follows from the pointer definition of array subscripting, > namely that a[e] is exactly equivalent to *((a)+(e)), for _any_ > expression e and primary expression a, as long as one of them is a > pointer expression. This unsuspected commutativity is often > mentioned in C texts as if it were something to be proud of, but it > finds no useful application outside of the Obfuscated C Contest (see > also question 83). ========== < The Standard has also been adopted as ISO/IEC 9899:1990, although < the Rationale is currently not included. --- > The Standard has also been adopted as an international standard, > ISO/IEC 9899:1990, although the Rationale is currently not included. ========== > Section 7. Lint > > 39. I just typed in this program, and it's acting strangely. Can you > see anything wrong with it? > > A: Try running lint first. Most C compilers are really only half- > compilers, electing not to diagnose numerous source code > difficulties which would not actively preclude code generation. > That the "other half," better error detection, was deferred to lint, > was a fairly deliberate decision on the part of the earliest Unix C > compiler authors, but is inexcusable (in the absence of a supplied, > consistent lint) in a modern compiler. > > 40. How can I shut off the "warning: possible pointer alignment problem" > message lint gives me for each call to malloc? > > A: The problem is that traditional versions of lint do not know, and > cannot be told, that malloc "returns a pointer to space suitably > aligned for storage of any type of object." It is possible to > provide a pseudoimplementation of malloc, using a #define inside of > #ifdef lint, which effectively shuts this warning off, but a > simpleminded #definition will also suppress meaningful messages > about truly incorrect invocations. It may be easier simply to > ignore the message, perhaps in an automated way with grep -v. > > 41. Where can I get an ANSI-compatible lint? > > A: A product called FlexeLint is available (in "shrouded source form," > for compilation on 'most any system) from > > Gimpel Software > 3207 Hogarth Lane > Collegeville, PA 19426 USA > (+1) 215 584 4261 > > Another product is MKS lint, from Mortice Kern Systems. At the > moment, I don't have their address, but you can send email to > inquiry@mks.com . > > 42. Don't ANSI function prototypes render lint obsolete? > > A: No. First of all, prototypes work well only if the programmer works > assiduously to maintain them, and the effort to do so (plus the > extra recompilations required by numerous, more-frequently-modified > header files) can rival the toil of keeping function calls correct > manually. Secondly, an independent program like lint will probably > always be more scrupulous at enforcing compatible, portable coding > practices than will a particular, implementation-specific, feature- > and extension-laden compiler. (Some vendors seem to introduce > incompatible extensions deliberately, perhaps to lock in market > share.) ========== alloca cannot be written portably, and is difficult to implement on machines without a stack. Its use is problematical (and the obvious implementation on a stack-based machine fails) when its return value is passed directly to another function, as in < fgets(alloca(100), stdin, 100). --- > fgets(alloca(100), 100, stdin). ========== A: This trick is popular, although Dennis Ritchie has called it < "unwarranted chumminess with the compiler." It is surprisingly < difficult to determine whether the ANSI C standard allows or < disallows it, but it is hard to imagine a compiler or architecture < for which it wouldn't work. (Debugging, array-bounds-checking < compilers might issue warnings.) --- > "unwarranted chumminess with the compiler." The ANSI C standard > allows it only implicitly. It seems to be portable to all known > implementations. (Debugging, array-bounds-checking compilers might > issue warnings.) ========== of curses have a nodelay() function. Depending on your system, you may also be able to use "nonblocking I/O", or a system call named < "select", or the FIONREAD ioctl, or the O_NDELAY option to open() or < fcntl(), or a kbhit() routine. --- > "select", or the FIONREAD ioctl, or kbhit(), or rdchk(), or the > O_NDELAY option to open() or fcntl(). ========== < A: BSD systems provide ftruncate(), and some PC compilers supply < chsize(), but there is no portable solution. --- > A: BSD systems provide ftruncate(), and several others supply chsize(), > but there is no truly portable solution. ========== > 73. How can I recover the file name given an open file descriptor? > > A: This problem is, in general, insoluble. Under Unix, for instance, a > scan of the entire disk, (perhaps requiring special permissions) > would be required, and would fail if the file descriptor were a pipe > (and could give a misleading answer for a file with multiple links). > It is best to remember the names of open files yourself (perhaps > with a wrapper function around fopen). > > > Section 14. Style > > 74. Here's a neat trick: > > if(!strcmp(s1, s2)) > > Is this good style? > > A: No. This is a classic example of C minimalism carried to an > obnoxious degree. The test succeeds if the two strings are equal, > but its form strongly suggests that it tests for inequality. > > A much better solution is to use a macro: > > #define Streq(s1, s2) (strcmp(s1, s2) == 0) > ========== 79. How can I write data files which can be read on other machines with different word size, byte order, or floating point formats? A: The best solution is to use a text file (usually ASCII), written < with fprintf and read with fscanf or the like. Be very skeptical of < arguments which imply that text files are too big, or that reading < and writing them is too slow. Not only is their efficiency < frequently acceptable in practice, but the advantages of being able < to manipulate them with standard tools can be overwhelming. --- > with fprintf and read with fscanf or the like. (Similar advice also > applies to network protocols.) Be very skeptical of arguments which > imply that text files are too big, or that reading and writing them > is too slow. Not only is their efficiency frequently acceptable in > practice, but the advantages of being able to manipulate them with > standard tools can be overwhelming. > > If the binary format is being imposed on you by an existing program, > first see if you can get that program changed to use a more portable > format. ========== Bellcore, and Carnegie Mellon. To find about f2c, send the mail message "send index from f2c" to < netlib@research.att.com or research!netlib. --- > netlib@research.att.com or research!netlib. (It is > also available via anonymous ftp on > research.att.com, in directory dist/f2c.) ========== > 83. Where can I get the winners of the old Obfuscated C Contests? When > will the next contest be held? > > A: Send mail to {pacbell,uunet,utzoo}!hoptoad!obfuscate . The contest > is usually announced in March, with entries due in May. Contest > announcements are posted in several obvious places. The winning > entries are archived on uunet (see question 82). ========== Don't assume that floating-point results will be exact, and especially don't assume that floating-point values can be compared < for equality. (Don't stick in random "fuzz factors," either.) --- > for equality. (Don't throw haphazard "fuzz factors" in, either.) ========== Thanks to Sudheer Apte, Mark Brader, Joe Buehler, Raymond Chen, > Christopher Calabrese, James Davies, Norm Diamond, Ray Dunn, Stephen M. > Dunn, Bjorn Engsig, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, > Karl Heuer, Blair Houghton, Kirk Johnson, Andrew Koenig, John Lauro, > Christopher Lott, Tim McDaniel, Evan Manning, Mark Moraes, Francois > Pinard, randall@virginia, Rich Salz, Chip Salzenberg, Paul Sand, Doug > Schmidt, Patricia Shanahan, Joshua Simons, Henry Spencer, Erik Talvola, > Clarke Thatcher, Chris Torek, Ed Vielmetti, and Freek Wiedijk, who have > contributed, directly or indirectly, to this article.