Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/C-faq/diff

Text File | 1993-11-04 | 17KB | 422 lines

Newsgroups: comp.lang.c,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!world!news.kei.com!eff!news.umbc.edu!europa.eng.gtefsd.com!uunet!nwnexus!oneworld!eskimo!scs
From: [e-mail] (Steve Summit)
Subject: comp.lang.c Changes to Answers to Frequently Asked Questions (FAQ)
Message-ID: <[e-mail]>
Followup-To: poster
Sender: [e-mail] (Steve Summit)
Reply-To: [e-mail]
X-Archive-Name: C-faq/diff
Organization: none, at the moment
Date: Thu, 4 Nov 1993 09:45:59 GMT
Approved: [e-mail]
Lines: 406
Xref: senator-bedfellow.mit.edu comp.lang.c:82573 comp.answers:2519 news.answers:14300

Archive-name: C-faq/diff
Comp-lang-c-archive-name: C-FAQ-list.diff

There are two significant changes this month, both long overdue:
The ANSI C Rationale is on-line (question 5.2), and an
Interpretation Ruling has declared the "struct hack" illegal
(question 9.6).  There is also the usual host of minor and
cosmetic changes.  (As usual, I haven't quite incorporated all of
the suggestions which had accumulated since the last major
update; if I promised to use your suggestion and you don't see
it, it's still on its way.)

Condensed context diffs follow.  (Don't try to feed these through
patch(1); wait instead for the full updated list, which should be
coming up next.)

==========
< [Last modified August 1, 1993 by scs.]
---
> [Last modified November 3, 1993 by scs.]
==========
< times.  Some vendors' compiler manuals are unfortunately inadequate; a
< few even perpetuate some of the myths which this article attempts to
---
> times.  Some C books and compiler manuals are unfortunately inadequate;
> a few even perpetuate some of the myths which this article attempts to
==========
  A:    The language definition states that for each pointer type, there
    is a special value -- the "null pointer" -- which is
    distinguishable from all other pointer values and which is not
<     the address of any object.  That is, the address-of operator &
---
>     the address of any object or function.  That is, the address-of
==========
<     pointer.  For instance, the Unix system call "execl" takes a
---
>     pointer.  For instance, the UNIX system call "execl" takes a
==========
<     (Note that many Unix manuals get this example wrong.)
---
>     (Note that many UNIX manuals get this example wrong.)
==========
    5.    The ASCII null character (NUL), which does have all bits
<         zero, but has no relation to the null pointer except in
<         name; and...
---
>         zero, but has no necessary relation to the null pointer
>         except in name; and...
==========
  A:    Much of the confusion surrounding pointers in C can be traced to
    a misunderstanding of this statement.  Saying that arrays and
<     pointers are "equivalent" does not by any means imply that they
<     are interchangeable.
---
>     pointers are "equivalent" neither means that they are identical
>     nor interchangeable.
==========
    question 2.2).  In either case, the expression x[i] (where x is
<     an array or a pointer) is, by definition, exactly equivalent to
<     *((x)+(i)).
---
>     an array or a pointer) is, by definition, identical to *((x)+(i)).
==========
  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
---
>     subscripting, namely that a[e] is identical to *((a)+(e)), for
>     _any_ expression e and primary expression a, as long as one of
==========
<         f2(aryp, m, n)
        int *aryp;
<         int m, n;
<         { ... ary[i][j] is really aryp[i * n + j] ... }
---
>         f2(aryp, nrows, ncolumns)
        int *aryp;
>         int nrows, ncolumns;
>         { ... ary[i][j] is really aryp[i * ncolumns + j] ... }
==========
>     It must be noted, however, that a program which performs
>     multidimensional array subscripting "by hand" in this way is not
>     in strict conformance with the ANSI C Standard; the behavior of
>     accessing (&array[0][0])[x] is not defined for x > NCOLUMNS.
==========
<     ; the following calls would be legal, and work as expected:
---
>     ; the following calls should work as expected:
==========
>     It must again be noted that passing array to f2() is not
>     strictly conforming; see question 2.11.
==========
<         main()
<         {
<             int *ip;
<             f(ip);
<             return 0;
<         }
---
>         ...
>         int *ip;
>         f(ip);
>         ...
==========
<             static int dummy;
            ip = &dummy;
<             *ip = 5;
---
>             static int dummy = 5;
            ip = &dummy;
==========
    Note that this example also uses fgets instead of gets (always a
<     good idea), so that the size of the array can be specified, so
---
>     good idea; see question 11.5), so that the size of the array can
==========
<     The Synopsis section at the top of a Unix-style man page can be
---
>     The Synopsis section at the top of a UNIX-style man page can be
==========
  A:    Since the two forms differ only in the value yielded, they are
<     entirely equivalent when only their side effect is needed.  Some
<     people will tell you that in the old days one form was preferred
<     over the other because it utilized a PDP-11 autoincrement
<     addressing mode, but those people are confused.
---
>     entirely equivalent when only their side effect is needed.
==========
<     The cost is $130.00 from ANSI or $162.50 from Global.
<     Copies of the original X3.159 (including the Rationale) are
<     still available at $205.00 from ANSI or $200.50 from Global.
<     (Editorial comment: yes, these prices are outrageous.)
<
<     Note that ANSI derives revenues to support its operations from
<     the sale of printed standards, so electronic copies are _not_
---
>     The cost is $130.00 from ANSI or $162.50 from Global.  Copies of
>     the original X3.159 (including the Rationale) are still
>     available at $205.00 from ANSI or $200.50 from Global.  Note
>     that ANSI derives revenues to support its operations from the
>     sale of printed standards, so electronic copies are _not_
==========
<     The Rationale, by itself, has been printed by Silicon Press,
<     ISBN 0-929306-07-4.
---
>     The text of the Rationale (not the full Standard) is now
>     available for anonymous ftp from ftp.uu.net (see question 17.8)
>     in directory doc/standards/ansi/X3.159-1989 .  The Rationale has
>     also been printed by Silicon Press, ISBN 0-929306-07-4.
==========
< A:    First, are you sure you really need to convert lots of old code
<     to ANSI C?  The old-style function syntax is still acceptable.
==========
<     March, 1992.  (See also question 17.8.)
---
>     March, 1992.  See also question 17.8.
==========
>     Finally, are you sure you really need to convert lots of old
>     code to ANSI C?  The old-style function syntax is still
>     acceptable.
==========
<     certain arguments when they are passed to functions.  Type float
    is promoted to double, and characters and short integers are
<     promoted to integers.  (The values are automatically converted
---
>     certain arguments when they are passed to functions.  floats are
     promoted to double, and characters and short integers are
>     promoted to ints.  (The values are automatically converted back
==========
  5.11:    Is exit(status) truly equivalent to returning status from main?

< A:    Yes, except under a few older, nonconforming systems.
---
> A:    Essentially, except under a few older, nonconforming systems,
>     and unless data local to main might be needed during cleanup
>     (due perhaps to a setbuf or atexit call).
==========
  5.16:    Is char a[3] = "abc"; legal?  What does it mean?

< A:    Yes, it is legal; it declares an array of size three,
    initialized with the three characters 'a', 'b', and 'c', without
<     the usual terminating '\0' character.
---
> A:    It is legal, though questionably useful.  It declares an array
    of size three, initialized with the three characters 'a', 'b',
>     and 'c', without the usual terminating '\0' character; the array
>     is therefore not a true C string and cannot be used with strcpy,
>     printf %s, etc.
==========
    used, but it will not work for floating-point values or
<     pointers, or if the two values are the same variable, (and the
---
>     pointers, or if the two values are the same variable (and the
==========
< 6.8:    I have some code which contains far too many #ifdef's for my
<     taste.  How can I preprocess the code to leave only one
---
> 6.8:    I inherited some code which contains far too many #ifdef's for
>     my taste.  How can I preprocess the code to leave only one
==========
<     Unix strings(1) utility.
---
>     UNIX strings(1) utility.
==========
  A:    This information is not available to a portable program.  Some
<     systems provide a nonstandard nargs() function, but its use is
<     questionable, since it typically returns the number of words
<     passed, not the number of arguments.  (Floating point values and
---
>     old systems provided a nonstandard nargs() function, but its use
>     was always questionable, since it typically returned the number
>     of words passed, not the number of arguments.  (Floating point
==========
<     The preprocessor macros TRUE and FALSE (and, of course, NULL)
    are used for code readability, not because the underlying values
<     might ever change.  (See also question 1.7.)
---
>     The preprocessor macros TRUE and FALSE are used for code
    readability, not because the underlying values might ever
>     change.  (See also questions 1.7 and 1.9.)
==========
A:    This technique is popular, although Dennis Ritchie has called it
<     "unwarranted chumminess with the compiler."  The ANSI C standard
<     allows it only implicitly.  It seems to be portable to all known
    implementations.  (Compilers which check array bounds carefully
---
>     "unwarranted chumminess with the compiler."  An ANSI
>     Interpretation Ruling has deemed it not strictly conforming.  It
>     seems, however, to be portable to all known implementations.
==========
    A similar problem, with a similar solution, can arise when
<     attempting to declare a pair of typedef'ed mutually recursive
---
>     attempting to declare a pair of typedef'ed mutually referential
    structures.
==========
< 10.4:    How do I declare an array of pointers to functions returning
---
> 10.4:    How do I declare an array of N pointers to functions returning
==========
< A:    This question can be answered in at least three ways (all
<     declare the hypothetical array with 5 elements):
---
> A:    This question can be answered in at least three ways:
==========
<     1.  char *(*(*a[5])())();
---
>     1.  char *(*(*a[N])())();
==========
<         pfpfpc a[5];        /* array of... */
---
>         pfpfpc a[N];        /* array of... */
==========
<         cdecl> declare a as array 5 of pointer to function returning
             pointer to function returning pointer to char
<         char *(*(*a[5])())()
---
>         cdecl> declare a as array of pointer to function returning
             pointer to function returning pointer to char
>         char *(*(*a[])())()
==========
<     that Unix compilers and linkers typically use a "common model"
---
>     that UNIX compilers and linkers typically use a "common model"
==========
  11.4:    Why won't the code

<         while(!feof(fp))
<             fgets(buf, MAXLINE, fp);
---
>         while(!feof(infp)) {
>             fgets(buf, MAXLINE, infp);
>             fputs(buf, outfp);
>         }

    work?
==========
    Usually, you should just check the return value of the input
<     routine (fgets in this case); feof() is rarely needed.
---
>     routine (fgets in this case); often, you don't need to use
>     feof() at all.
==========
<     to use fgets() to read a whole line, and then use sscanf or
---
>     to use fgets to read a whole line, and then use sscanf or other
==========
< A:    This problem is, in general, insoluble.  Under Unix, for
---
> A:    This problem is, in general, insoluble.  Under UNIX, for
==========
<             time_t now;
<             time(&now);
---
>             time_t now = time((time_t *)NULL);
            printf("It's %.24s.\n", ctime(&now));
==========
< A:    Unix and some other systems provide a popen() routine, which
---
> A:    UNIX and some other systems provide a popen() routine, which
==========
<     are available on most Unix systems.  Implementations also exist
---
>     are available on most UNIX systems.  Implementations also exist
==========
<     separately (bundled with other C tools) from Unix Support Labs
---
>     separately (bundled with other C tools) from UNIX Support Labs
==========
<     instance, under Unix, you usually need to use the -lm option,
---
>     instance, under UNIX, you usually need to use the -lm option,
==========
  15.3:    Why doesn't C have an exponentiation operator?

< A:    You can #include <math.h> and use the pow() function, although
---
> A:    Because few processors have an exponentiation instruction.
>     Instead, you can #include <math.h> and use the pow() function,
==========
<     name/value functionality similar to the Unix environment in
---
>     name/value functionality similar to the UNIX environment in
==========
<     Under Unix, a process can modify its own environment (some
---
>     Under UNIX, a process can modify its own environment (some
==========
<     determine this number in advance.  Under Unix, the stat call
---
>     determine this number in advance.  Under UNIX, the stat call
==========
<     a Unix-like stat which will give an approximate answer.  You can
---
>     a UNIX-like stat which will give an approximate answer.  You can
==========
<     nonportable (it gives you an accurate answer only under Unix,
---
>     nonportable (it gives you an accurate answer only under UNIX,
==========
< A:    Unfortunately, there is no portable way.  V7 Unix, and derived
---
> A:    Unfortunately, there is no portable way.  V7 UNIX, and derived
==========
    System V and Posix.  Other routines you might look for on your
<     system include clock() and gettimeofday().  The select() and
---
>     system include nap(), setitimer(), msleep(), usleep(), clock(),
>     and gettimeofday().  The select() and poll() calls (if
==========
<     BSD Unix, you could use system() and ld -A to do the linking for
---
>     BSD UNIX, you could use system() and ld -A to do the linking for
==========
    static), are guaranteed initialized to zero, as if the
    programmer had typed "= 0".  Therefore, such variables are
<     initialized to the null pointer (of the correct type) if they
---
>     initialized to the null pointer (of the correct type; see also
>     Section 1) if they are pointers, and to 0.0 if they are
    floating-point.
==========
    Then, just search the table for the name, and call through the
<     associated function pointer.
---
>     associated function pointer.  See also questions 9.8 and 16.10.
==========
<     which can be sped up by using buffering and cacheing techniques.
---
>     which can be sped up by using buffering and caching techniques.
==========
<     which perform dynamic stack allocation automatically (e.g. Unix)
---
>     which perform dynamic stack allocation automatically (e.g. UNIX)
==========
< A:    Mitch Wright maintains an annotated bibliography of C and Unix
---
> A:    Mitch Wright maintains an annotated bibliography of C and UNIX
==========
  Thanks to Jamshid Afshar, Sudheer Apte, Randall Atkinson, Dan Bernstein,
  Vincent Broman, Stan Brown, Joe Buehler, Gordon Burditt, Burkhard Burow,
  D'Arcy J.M. Cain, Christopher Calabrese, Paul Carter, Raymond Chen,
> Jonathan Coxhead, James Davies, Jutta Degener, Norm Diamond, Ray Dunn,
  Stephen M. Dunn, Bjorn Engsig, Alexander Forst, Jeff Francis, Dave
  Gillespie, Samuel Goldstein, Alasdair Grant, Ron Guilmette, Doug Gwyn,
  Tony Hansen, Joe Harrington, Guy Harris, Jos Horsmeier, Blair Houghton,
> Kirk Johnson, Peter Klausler, Andrew Koenig, Tom Koenig, Ajoy
> Krishnan T, John Lauro, Felix Lee, Don Libes, Christopher Lott, Tim
> McDaniel, John R. MacMillan, Bob Makowski, Evan Manning, Barry Margolin,
  Brad Mears, Mark Moraes, Darren Morby, Landon Curt Noll, David O'Brien,
  Richard A. O'Keefe, Hans Olsson, Francois Pinard, Pat Rankin, Erkki
  Ruohtula, Rich Salz, Chip Salzenberg, Paul Sand, Doug Schmidt, Patricia
  Shanahan, Peter da Silva, Joshua Simons, Henry Spencer, David Spuler,
  Erik Talvola, Clarke Thatcher, Wayne Throop, Chris Torek, Goran
> Uddeborg, Rodrigo Vanegas, Wietse Venema, Ed Vielmetti, Larry Virden,
  Chris Volpe, Freek Wiedijk, Dave Wolverton, Mitch Wright, Conway Yee,
  and Zhuo Zang, who have contributed, directly or indirectly, to this
  article.  Special thanks to Karl Heuer, and particularly to Mark Brader,
  who (to borrow a line from Steve Johnson) have goaded me beyond my
  inclination, and occasionally beyond my endurance, in relentless pursuit
  of a better FAQ list.
==========

                    Steve Summit
                    [e-mail]