Danny Amor's Online Library/Danny Amor's Online Library - Volume 1.iso/html/faqs/faq/c-faq/diff

Text File | 1995-07-25 | 16.5 KB | 414 lines

Subject: comp.lang.c Changes to Answers to Frequently Asked Questions (FAQ)
Newsgroups: comp.lang.c,comp.answers,news.answers
From: [e-mail] (Steve Summit)
Date: 1 May 94 10:00:53 GMT

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

This article contains a massaged diff list comparing the previous
revision of the comp.lang.c frequently-asked questions list
(last modified March 1, 1994, last posted April 1) and the
current one.  Due to the massaging (which is intended to make the
changes easier to see), this list is not suitable for input to a
patch program.

As usual, there are more changes in the works than are reflected
in this month's posting.  If you have made a suggestion or
correction which you think vital, but which you do not see here,
don't panic: though the mills of FAQ list revision grind slowly,
yet they grind exceeding fine (with apologies to von Logau).

==========
< [Last modified March 1, 1994 by scs.]
---
> [Last modified April 16, 1994 by scs.]
==========
  1.5:    If NULL were defined as follows:

<         #define NULL (char *)0
---
>         #define NULL ((char *)0)
==========
  A:    This message, which occurs only under MS-DOS (see, therefore,
<     section 16) means that you've written, via a null pointer, to
<     location zero.
---
>     section 16) means that you've written, via an unintialized
>     and/or null pointer, to location zero.
==========
< A:    There is no single perfect method.  Given a function f1()
<     similar to the f() of question 2.10, the array as declared in
<     question 2.10, f2() as declared in question 2.11, array1,
<     array2, array3, and array4 as declared in question 2.14, and a
<     function f3() declared as:
<
<         f3(pp, m, n)
<         int **pp;
<         int m, n;
<
<     ; the following calls should work as expected:
---
> A:    There is no single perfect method.  Given the declarations
>
>         int array[NROWS][NCOLUMNS];
>         int **array1;
>         int **array2;
>         int *array3;
>         int (*array4)[NCOLUMNS];
>
>     as initialized in the code fragments in questions 2.10 and 2.14,
>     and functions declared as
>
>         f1(int a[][NCOLUMNS], int m, int n);
>         f2(int *aryp, int nrows, int ncolumns);
>         f3(int **pp, int m, int n);
>
>     (see questions 2.10 and 2.11), the following calls should work
>     as expected:
==========
  A:    Did the function try to initialize the pointer itself, or just
    what it pointed to?  Remember that arguments in C are passed by
    value.  The called function altered only the passed copy of the
<     pointer.  You'll want to pass the address of the pointer (the
<     function will end up accepting a pointer-to-a-pointer).
---
>     pointer.  You'll either want to pass the address of the pointer
>     (the function will end up accepting a pointer-to-a-pointer), or
>     have the function return the pointer.
==========
<     Note that this example also uses fgets instead of gets (always a
<     good idea; see question 11.5), allowing the size of the array to
---
>     Note that this example also uses fgets() instead of gets()
>     (always a good idea; see question 11.6), allowing the size of
==========
    The programmer must arrange (explicitly) for sufficient space
    for the results of run-time operations such as string
    concatenation, typically by declaring arrays, or by calling
<     malloc.
---
>     malloc.  (See also question 17.20.)
==========
  A:    Make sure that the memory to which the function returns a
    pointer is correctly allocated.  The returned pointer should be
    to a statically-allocated buffer, or to a buffer passed in by
<     the caller, but _not_ to a local (auto) array.  In other words,
<     never do something like
---
>     the caller, or to memory obtained with malloc(), but _not_ to a
>     local (auto) array.  In other words, never do something like
==========
<     One fix would to to declare the buffer as
---
>     One fix (which is imperfect, especially if f() is called
>     recursively, or if several of its return values are needed
>     simultaneously) would to to declare the buffer as

            static char buf[10];
==========
  A:    Before ANSI/ISO Standard C introduced the void * generic pointer
    type, these casts were typically required to silence warnings
<     about assignment between incompatible pointer types.
---
>     about assignment between incompatible pointer types.  (Under
>     ANSI/ISO Standard C, these casts are not required.)
==========
  A:    Most implementations of malloc/free do not return freed memory
    to the operating system (if there is one), but merely make it
<     available for future malloc calls.
---
>     available for future malloc calls within the same process.
==========
  A:    There is a special exception for those operators, (as well as
<     ?: ); each of them does imply a sequence point (i.e. left-to-
---
>     the ?: operator); each of them does imply a sequence point (i.e.
==========
    hand-side.  Use an explicit cast to force long arithmetic:

        long int c = (long int)a * b;

>     Note that the code (long int)(a * b) would _not_ have the
>     desired effect.
==========
  5.13:    Is exit(status) truly equivalent to returning status from main?

< 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).
---
> A:    Formally, yes, although discrepancies arise under a few older,
>     nonconforming systems, or if data local to main() might be needed
>     during cleanup (due perhaps to a setbuf or atexit call), or if
>     main() is called recursively.
==========
    Before performing arithmetic, cast the pointer either to char *
<     or to the type you're trying to manipulate.
---
>     or to the type you're trying to manipulate (but see question
>     2.18).
==========
< 5.22:    What does #pragma once mean?  I found it in some header files.
---
> 5.22:    What does "#pragma once" mean?  I found it in some header files.
==========
  6.9:    How can I list all of the pre#defined identifiers?

< A:    There's no standard way, although it is a frequent need.  The
<     most expedient way is probably to extract printable strings from
<     the compiler or preprocessor executable with something like the
<     Unix strings(1) utility.
---
> A:    There's no standard way, although it is a frequent need.  If the
>     compiler documentation is unhelpful, the most expedient way is
>     probably to extract printable strings from the compiler or
>     preprocessor executable with something like the Unix strings(1)
>     utility.  Beware that many traditional system-selective
>     pre#defined identifiers (e.g. "unix") are non-Standard (because
>     they clash with the user's namespace) and are being removed or
>     renamed.
==========
    A good rule of thumb is to use TRUE and FALSE (or the like) only
<     for assignment to a Boolean variable, or as the return value
<     from a Boolean function, never in a comparison.
---
>     for assignment to a Boolean variable or function parameter, or
>     as the return value from a Boolean function, but never in a
>     comparison.
==========
  10.6:    My compiler is complaining about an invalid redeclaration of a
    function, but I only define it once and call it once.

< A:    If the first call precedes the definition, the compiler will
<     assume a function returns an int.  Non-int functions must be
---
> A:    Functions which are called without a declaration in scope (or
>     before they are declared) are assumed to be declared as
>     returning int, leading to discrepancies if the function is later
>     declared otherwise.  Non-int functions must be declared before
>     they are called.
==========
< 11.1:    Why doesn't this code:
<
<        char c;
<        while((c = getchar()) != EOF)...
<
<     work?
---
> 11.1:    What's wrong with this code:
<
<        char c;
<        while((c = getchar()) != EOF)...
==========
    well as EOF.  By passing getchar's return value through a char,
    either a normal character might be misinterpreted as EOF, or the
<     EOF might be altered and so never seen.
---
>     EOF might be altered (particularly if type char is unsigned) and
>     so never seen.
==========
> 11.2:    How can I print a '%' character in a printf format string?  I
>     tried \%, but it didn't work.
>
> A:    Simply double the percent sign: %% .
>
>     References: K&R I Sec. 7.3 p. 147; K&R II Sec. 7.2 p. 154; ANSI
>     Sec. 4.9.6.1 .
2575c2585
< 11.9:    I'm trying to update a file in place, by using fopen mode "r+",
---
> 11.10:    I'm trying to update a file in place, by using fopen mode "r+",
==========
  A:    Be sure to call fseek before you write, both to seek back to the
    beginning of the string you're trying to overwrite, and because
    an fseek or fflush is always required between reading and
<     writing in the read/write "+" modes.
---
>     writing in the read/write "+" modes.  Also, remember that you
>     can only overwrite characters with the same number of
>     replacement characters; see also question 17.4.
==========
        int mystructcmp(p1, p2)
        char *p1, *p2;        /* const void * for ANSI C */
        {
            struct mystruct *sp1 = (struct mystruct *)p1;
            struct mystruct *sp2 = (struct mystruct *)p2;
<             /* now compare sp1->whatever and *sp2-> ... */
---
>             /* now compare sp1->whatever and sp2-> ... */
==========
  12.7:    How can I add n days to a date?  How can I find the difference
    between two dates?

  A:    The ANSI/ISO Standard C mktime and difftime functions provide
<     support for both problems.  mktime accepts non-normalized dates,
---
>     some support for both problems.  mktime() accepts non-normalized
==========
<     dates to be subtracted.  (Note, however, that these solutions
<     only work for dates which can be represented as time_t's.)  See
<     also questions 12.6 and 17.28.
---
>     time_t values for two dates to be subtracted.  (Note, however,
>     that these solutions only work for dates in the range which can
>     be represented as time_t's, and that not all days are 86400
>     seconds long.)  See also questions 12.6 and 17.28.
==========
< 12.12: I'm trying to port this    A:  These routines are variously
<     old program.  Why do I            obsolete; you should
<     get "undefined external"        instead:
---
> 12.12: I'm trying to port this    A:  Those routines are variously
>     old program.  Why do I            obsolete; you should
>     get "undefined external"        instead:
==========
    undefined.  Therefore, the order in which libraries are listed
    with respect to object files (and each other) is significant;
<     usually, you want to search the libraries last (i.e., under
<     Unix, put any -l switches towards the end of the command line).
---
>     usually, you want to search the libraries last.  (For example,
>     under Unix, put any -l switches towards the end of the command
>     line.)
==========
< 12.16: How can I split up a command line into argc and argv, like the
<     shell does?
---
> 12.16: How can I split up a command line into whitespace-separated
>     arguments, like main's argc and argv?
==========
< A:    Most systems have a routine called strtok.
---
> A:    Most systems have a routine called strtok, although it can be
>     tricky to use and it may not do everything you want it to (e.g.,
>     quoting).
==========
    The System V release 4 lint is ANSI-compatible, and is available
    separately (bundled with other C tools) from UNIX Support Labs
<     (a subsidiary of AT&T), or from System V resellers.
---
>     or from System V resellers.
==========
>     In the absence of lint, many modern compilers attempt to
>     diagnose almost as many problems as a good lint does.
==========
<         giza.cis.ohio-state.edu    pub/style-guide
---
>         ftp.cs.umd.edu          pub/style-guide
==========
  16.7:    How can I check whether a file exists?  I want to query the user
<     if a requested output file already exists.
---
>     before overwriting existing files.
==========
< A:    You can try the access() routine, although it's got a few
<     problems.  (It isn't atomic with respect to the following
<     action, and it has anomalies if the program calling it is
<     running as root.)
---
> A:    On Unix-like systems, you can try the access() routine, although
>     it's got a few problems.  (It isn't atomic with respect to the
>     following action, and can have anomalies if used in setuid
>     programs.)  Another option (perhaps preferable) is to call
>     stat() on the file.  Otherwise, the only guaranteed and portable
>     way to test for file existence is to try opening the file (which
>     doesn't help if you're trying to avoid overwriting an existing
>     file, unless you've got something like the BSD Unix O_EXCL open
>     option available).
==========
  A:    Unix and some other systems provide a popen() routine, which
    sets up a stdio stream on a pipe connected to the process
    running a command, so that the output can be read (or the input
<     supplied).
---
>     supplied).  Alternately, invoke the command simply (see question
>     16.12) in such a way that it writes its output to a file, then
>     open and read that file.
==========
A:    Perhaps you have a pre-ANSI compiler, which doesn't allow
    initialization of "automatic aggregates" (i.e. non-static local
    arrays and structures).  As a workaround, you can make the array
<     global or static.  (You can always initialize local char *
---
>     global or static, and initialize it with strcpy when f is
>     called.  (You can always initialize local char * variables with
==========
< 17.4:    How can I delete a line (or record) from the middle of a file?
---
> 17.4:    How can I insert or delete a line (or record) in the middle of a
>     file?
==========
    f2c    A Fortran to C converter jointly developed by people
        from Bell Labs, Bellcore, and Carnegie Mellon.  To find
<         about f2c, send the mail message "send index from f2c"
<         to [e-mail] or research!netlib.  (It is
<         also available via anonymous ftp on research.att.com, in
<         directory dist/f2c.)
---
>         out more about f2c, send the mail message "send index
>         from f2c" to [e-mail] or research!netlib.
>         (It is also available via anonymous ftp on
>         netlib.att.com, in directory netlib/f2c.)
==========
    (or ask archie; see question 17.12); and MEMDEBUG from
<     dorado.crpht.lu in pub/sources/memdebug .  See also question
<     17.12.
---
>     ftp.crpht.lu in pub/sources/memdebug .  See also question 17.12.
==========
  A:    Use mktime (see questions 12.6 and 12.7), or Zeller's
<     congruence.  Here is one quick implementation posted by Tomohiko
<     Sakamoto:
---
>     congruence, or see the sci.math FAQ list, or try this code
>     posted by Tomohiko Sakamoto:
==========
<     garbo.uwasa.fi:/pc/c/c-lesson.zip
<     oak.oakland.edu:pub/msdos/c/LEARN-C.ZIP
---
>     garbo.uwasa.fi:/pc/c-lang/c-lesson.zip
==========
<     other FAQ lists, including this one: two sites are rtfm.mit.edu
---
>     other FAQ lists, including this one; two sites are rtfm.mit.edu
==========
  Acknowledgements

  Thanks to Jamshid Afshar, Sudheer Apte, Randall Atkinson, Dan Bernstein,
  Vincent Broman, Stan Brown, Joe Buehler, Gordon Burditt, Burkhard Burow,
  Conor P. Cahill, D'Arcy J.M. Cain, Christopher Calabrese, Ian Cargill,
> Paul Carter, Billy Chambless, Raymond Chen, Jonathan Coxhead, Lee
  Crawford, Steve Dahmer, Andrew Daviel, James Davies, Jutta Degener, Norm
  Diamond, Jeff Dunlop, Ray Dunn, Stephen M. Dunn, Michael J. Eager, Dave
  Eisen, Bjorn Engsig, Chris Flatters, Rod Flores, Alexander Forst, Jeff
  Francis, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron
  Guilmette, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Elliotte
  Rusty Harold, Jos Horsmeier, Blair Houghton, Ke Jin, Kirk Johnson, Larry
  Jones, Kin-ichi Kitano, Peter Klausler, Andrew Koenig, Tom Koenig, Ajoy
  Krishnan T, Markus Kuhn, John Lauro, Felix Lee, Mike Lee, Timothy J.
  Lee, Tony Lee, Don Libes, Christopher Lott, Tim Love, Tim McDaniel,
  Stuart MacMartin, John R. MacMillan, Bob Makowski, Evan Manning, Barry
  Margolin, George Matas, Brad Mears, Bill Mitchell, Mark Moraes, Darren
  Morby, Ken Nakata, Landon Curt Noll, David O'Brien, Richard A. O'Keefe,
> Hans Olsson, Philip ([e-mail]), Andrew Phillips,
  Christopher Phillips, Francois Pinard, Dan Pop, Kevin D. Quitt, Pat
  Rankin, J. M. Rosenstock, Erkki Ruohtula, Tomohiko Sakamoto, Rich Salz,
  Chip Salzenberg, Paul Sand, DaviD W. Sanderson, Christopher Sawtell,
> Paul Schlyter, Doug Schmidt, Rene Schmit, Russell Schulz, Patricia
  Shanahan, Peter da Silva, Joshua Simons, Henry Spencer, David Spuler,
  Melanie Summit, Erik Talvola, Clarke Thatcher, Wayne Throop, Chris
  Torek, Andrew Tucker, Goran Uddeborg, Rodrigo Vanegas, Jim Van Zandt,
  Wietse Venema, Ed Vielmetti, Larry Virden, Chris Volpe, Mark Warren,
  Larry Weiss, Freek Wiedijk, Lars Wirzenius, 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]