Changes to Answers to Frequently Asked Questions (FAQ) on comp.lang.c

[Steve Summit]

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 at 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 at research.att.com or research!netlib.
---
>                     netlib at 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 at 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.