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

[Steve Summit]

Coming up next is the real comp.lang.c FAQ list.  (Accept no
substitutes!)  There are no major changes this month; a brief
diff listing follows.  (As always, these diffs have been edited
for readability, and are not suitable for the patch program.)

==========
< [Last modified February 28, 1991 by scs.]
---
> [Last modified April 2, 1991 by scs.]
==========
<       An identifier of type array-of-T which appears in an
        expression decays (with three exceptions) into a pointer to
        its first element; the type of the resultant pointer is
        pointer-to-T.
---
>       An lvalue of type array-of-T which appears in an expression
==========
       as it applies to arrays and pointers.  In an expression of the form
<      a[i], the array name "a" decays into a pointer, following the rule
       above, and is then subscripted exactly as would be a pointer
       variable in the expression p[i].  In either case, the expression
---
>      a[i], the array reference "a" decays into a pointer, following the
==========
<      Since strcat returns its first argument, the s3 variable is
<      superfluous.
---
>      Since strcat returns the value of its first argument, the s3
>      variable is superfluous.
==========
  A:   In general, when using pointers you _always_ have to consider
       memory allocation, at least to make sure that the compiler is doing
<      it for you.
---
>      it for you.  If a library routine's documentation does not
>      explicitly mention allocation, it is usually the caller's problem.
==========
       it is not widely portable.  Passing an initially-null pointer to
<      realloc can make it easy to write a self-starting incremental
       allocation algorithm.
---
>      realloc can make it easier to write a self-starting incremental
==========
       structures), use short.  Otherwise, use int.  If well-defined
<      overflow characteristics are important and/or sign is not, use
<      unsigned.
---
>      overflow characteristics are important and/or negative values are
>      not, use unsigned.  (But beware mixtures of signed and unsigned.)
==========
<      In general, don't try to use char or unsigned char as a "tiny" int
<      type; doing so is often more trouble than it's worth.
---
>      Although char or unsigned char can be used as a "tiny" int type;
>      doing so is often more trouble than it's worth.
==========
       may also generate nonfatal warnings when enums and ints are
       indiscriminately mixed, since doing so can still be considered bad
       style even though it is not strictly illegal).  A disadvantage is
<      that the programmer has little control over the size.
---
>      that the programmer has little control over the size (or over those
>      nonfatal warnings).
==========
<      calculator.  A good compiler will generate identical code for i++,
<      i += 1, and i = i + 1.  The reasons for using i++ or i += 1 over
       i = i + 1 have to do with style, not efficiency.
---
>      calculator.  A good compiler will generate identical code for ++i,
>      i += 1, and i = i + 1.  The reasons for using ++i or i += 1 over
==========
  Acknowledgements

> Thanks to Sudheer Apte, Dan Bernstein, Joe Buehler, Raymond Chen,
> Christopher Calabrese, James Davies, Norm Diamond, Ray Dunn, Stephen
> M. Dunn, Bjorn Engsig, Ron Guilmette, Doug Gwyn, Tony Hansen, Joe
> Harrington, Guy Harris, Blair Houghton, Kirk Johnson, Andrew Koenig,
> John Lauro, Christopher Lott, Tim McDaniel, Evan Manning, Mark Moraes,
> Francois Pinard, randall at virginia, Pat Rankin, Rich Salz, Chip
> Salzenberg, Paul Sand, Doug Schmidt, Patricia Shanahan, Peter da Silva,
> Joshua Simons, Henry Spencer, Erik Talvola, Clarke Thatcher, Chris
> Torek, Ed Vielmetti, Larry Virden, Freek Wiedijk, and Dave Wolverton,
> who have contributed, directly or indirectly, to this article.

                                             Steve Summit
                                             scs at adam.mit.edu
                                             scs%adam.mit.edu at mit.edu
                                             mit-eddie!adam!scs