Changes to Answers to Frequently Asked Questions (FAQ) on comp.lang.c
Steve Summit
scs at adam.mit.edu
Wed Jul 18 13:47:43 AEST 1990
(This diff listing has been edited for readability and is not suitable
for the patch program.)
93,98c68,71
< Although a null pointer does not "point anywhere," it is different
< from an uninitialized pointer, about which we cannot say where it
< points. A null pointer points explicitly nowhere (i.e. not at any
< object); an uninitialized pointer might point anywhere (at some
< random object, or at a garbage or unallocated address). See also
< question 29.
---
> A null pointer is different from an uninitialized pointer. A null
> pointer is known not to point to any object; an uninitialized
> pointer might point anywhere (that is, at some random object, or at
> a garbage or unallocated address). See also question 30.
114,115c87,88
< in an assignment or comparison when one side is a variable of
< pointer type, the compiler can tell that a constant 0 on the other
---
> in an initialization, assignment, or comparison when one side is a
> variable or expression of pointer type, the compiler can tell that a
165,169c142,145
< A: Not since the early days. It is now merely guaranteed that a
< pointer to an object may be cast to a "suitably capacious" integral
< type, and back, without change, but how large the type is is not
< specified (it may be larger than a long int) and the rule does _not_
< apply to pointers to functions. (Any object pointer may be cast to
---
> A: Not since the early days. Attempting to push pointers into
> integers, or build pointers out of integers, has always been
> machine-dependent and unportable, and doing so is strongly
> discouraged. (Any object pointer may be cast to the "universal"
224,227c200,204
< different kinds of pointers for different types of data. The
< suggested #definition would make uncast NULL arguments to functions
< expecting pointers to characters to work correctly, but pointer
< arguments to other types would still be problematical.
---
> different internal representations for pointers to different types
> of data. The suggested #definition would make uncast NULL arguments
> to functions expecting pointers to characters to work correctly, but
> pointer arguments to other types would still be problematical, and
> legal constructions such as
228a206,209
> FILE *fp = NULL;
>
> could fail.
>
240,241c221,222
< A: This definition, like (void *)0, helps incorrect programs work on
< some common architectures.
---
> A: This definition (the third approved one, besides 0 and (void *)0)
> helps incorrect programs work on some architectures.
249,250c230,231
< operators), a false value is produced when the expression is equal
< to zero, and a true value otherwise. That is, whenever one writes
---
> operators), a false value is produced when the expression compares
> equal to zero, and a true value otherwise. That is, whenever one
287,288c271,272
< and that an uncast "0" is perfectly acceptable in assignment and
< comparison contexts. Any usage of "NULL" (as opposed to "0") should
---
> and that an uncast "0" is perfectly acceptable in initialization,
> assignment, and comparison contexts. Any usage of "NULL" (as
300,302c285,288
< A: No. NULL is defined as a preprocessor macro _not_ because its value
< might change. That source-code 0's generate null pointers is
< guaranteed by the language. NULL is used only as a stylistic
---
> A: No. Although preprocessor macros are often used in place of numbers
> because the numbers might change, this is _not_ the reason that NULL
> is used in place of 0. The language guarantees that source-code 0's
> (in pointer contexts) generate null pointers. NULL is used only as
315,316c301,302
< When the phrase "null pointer" is casually used, one of three things
< may be meant:
---
> When the term "null" or "NULL" is casually used, one of several
> things may be meant:
318a304,305
> 1. The conceptual null pointer, the abstract language concept
> defined in question 1. It is implemented with...
327a316,319
> Finally, as a red herring, we have
>
> 5. The ASCII null character (NUL), which does have all bits zero,
> but has no relation to the null pointer except in name.
336,342c329,338
< about the underlying machine implementation. The fact that null
< pointers are represented both in source code, and internally to most
< machines, as zero invites unwarranted assumptions. The fact that a
< preprocessor macro (NULL) is often used suggests that this is done
< because the value might change later, or on some weird machine.
< Furthermore, the distinction between the three uses of the term
< "null" (listed above) is often overlooked.
---
> about the underlying machine implementation. The construct
> "if(p == 0)" is easily misread as calling for conversion of p to an
> integral type, rather than 0 to a pointer type, before the
> conversion. The fact that null pointers are represented both in
> source code, and internally to most machines, as zero invites
> unwarranted assumptions. The fact that a preprocessor macro (NULL)
> is often used suggests that this is done because the value might
> change later, or on some weird machine. Furthermore, the
> distinction between the four uses of the term "null" (listed above)
> is often overlooked.
383,389c379,390
< array, usually unsized) holds _only_ for formal arguments to
< functions. This identity falls out of the fact that arrays "turn
< into" pointers in expressions. That is, when an array name is
< mentioned in an expression, it is converted immediately into a
< pointer to the array's first element. Therefore, an array is never
< passed to a function; rather a pointer to its first element is
< passed instead.
---
> array declaration, usually unsized) holds _only_ for formal
> parameters to functions. This identity is related to the fact that
> arrays "turn into" pointers in expressions. That is, when an array
> name is mentioned in an expression, it is converted immediately into
> a pointer to the array's first element. Therefore, an array is
> never passed to a function; rather a pointer to its first element is
> passed instead. Allowing pointer parameters to be declared as
> arrays is a simply a way of making it look as though the array was
> actually being passed. Some programmers prefer, as a matter of
> style, to use this syntax to indicate that the pointer parameter is
> expected to point to the start of an array rather than to a single
> value.
409,410c413,414
< A: Perhaps no aspect of C is more confusing than pointers, and no
< statement has compounded this confusion more than the one above.
---
> A: Perhaps no aspect of C is more confusing than pointers, and the
> confusion is compounded by statements like the one above.
455a458,460
> The order of other embedded side effects is similarly undefined.
> For example, the expression i + (i = 2) may or may not have the
> value 4.
459a465,473
> 18. But what about the &&, ||, and ?: operators?
> I see code like "if((c = getchar()) == EOF || c == '\n')" ...
>
> A: There is a special exception for those operators; each of them does
> imply a sequence point (i.e. left-to-right evaluation is
> guaranteed).
>
> References: ANSI X3.159-1989 Sec. 3.3.2.2, 3.3.13, 3.3.14, 3.3.15 .
>
489c506,507
< The cost is approximately $50.00, plus $6.00 shipping.
---
> The cost is approximately $50.00, plus $6.00 shipping. Quantity
> discounts are available.
505,507c523,525
< with the old-style definition "int blort(x) float x;". Old C
< silently promoted doubles to floats when passing them as arguments,
< and made a corresponding silent change to formal argument
---
> with the old-style definition "int blort(x) float x;". Old C (and
> ANSI C, in the absence of prototypes) silently promotes floats to
> doubles when passing them as arguments, and makes a corresponding
547c567,569
< of a character constant) and no newlines inside quotes.
---
> of a character constant) and no newlines inside quotes. Therefore,
> natural-language comments should always be written between the
> "official" comment delimiters /* and */.
627c651
< Using varargs, rather than stdarg, requires a few changes which are
---
> Using the older varargs package, rather than stdarg, requires a few
638c662
< A: Use v*printf.
---
> A: Use vprintf, vfprintf, or vsprintf.
677c696,697
< between the calls to va_start and vfprintf.
---
> between the calls to va_start and vfprintf. (Note that there is no
> semicolon after va_dcl.)
686c706
< systems have a nonstandard nargs() function available, but even this
---
> systems have a nonstandard nargs() function available, but its use
707,709c727,729
< example above. If the arguments must be passed as arguments (not
< indirectly through a va_list pointer) to another function which is
< itself varargs (for which you do not have the option of creating an
---
> example above. If the arguments must be passed directly as actual
> arguments (not indirectly through a va_list pointer) to another
> function which is itself variadic (for which you do not have the
716c736
< 29. Why doesn't this program work?
---
> 30. Why doesn't this program work?
721c741
< printf("Type something: ");
---
> printf("Type something:\n);
759c779,781
< treatment of the trailing \n.)
---
> treatment of the trailing \n.) It would also be possible to use
> malloc to allocate the answer buffer, and/or to parameterize its
> size (#define ANSWERSIZE 100).
760a783,797
> 31. What is alloca and why is its use discouraged?
>
> A: alloca allocates memory which is automatically freed when the
> function from which alloca was called returns. That is, memory
> allocated with alloca is local to a particular function's "stack
> frame" or context.
>
> 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).
>
> For these reasons, alloca cannot be used in programs which must be
> widely portable, no matter how useful it might be.
764,764c802,802
< and from functions, but K&R I says no.
---
> and from functions, but K&R I says not.
807c845
< this case, by the C start-up code). Storing a structure into memory
---
> this case, by the C start-up code). Attempting to store a structure
836c874,875
< #define offset(type, mem) ((size_t)(char *)&(((type *)0)->mem))
---
> #define offsetof(type, mem) ((size_t) \
> ((char *)&(((type) *) 0)->mem - (char *)&(((type) *) 0)))
838,839c877,878
< This implementation's use of the null pointer, however, is said not
< to be completely portable.
---
> This implementation is not 100% portable; some compilers may refuse
> to accept it.
867c908
< but the compiler gave me errors. Can't a struct in C contain a
---
> but the compiler gave me error messages. Can't a struct in C
936,937c977,978
< within, the definitions for struct a and struct b. The problem
< arises when an attempt is made to define and use a typedef within
---
> within, the definitions for struct a and struct b. Problems arise
> only when an attempt is made to define and use a typedef within the
972,974c1012,1013
< A: Several public-domain versions are available. A file called
< "cdecl.shar" is available for anonymous ftp from mimsy.umd.edu
< (128.8.128.8), or check your local archive.
---
> A: Several public-domain versions are available. One is in volume 14
> of comp.sources.unix .
1007c1045
< These don't really buy much (see below).
---
> These don't buy anything (see below).
1024c1061,1063
< _not_ necessarily 1.
---
> _not_ necessarily 1. 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.
1043,1049c1083,1089
< For now, the advantages of enums (other than that the numeric values
< are automatically assigned) are that a compiler may generate
< nonfatal warnings when enums and ints are indiscriminately mixed
< (such mixing can still be considered bad style even though it is not
< strictly illegal) or when enum cases are left out of switch
< statements; and that a debugger may be able to display the symbolic
< values when enum variables are examined.
---
> The advantages of enums are that the numeric values are
> automatically assigned, that a debugger may be able to display the
> symbolic values when enum variables are examined, and that a
> compiler may generate nonfatal warnings when enums and ints are
> indiscriminately mixed (such mixing can still be considered bad
> style even though it is not strictly illegal) or when enum cases are
> left out of switch statements.
1062,1063c1102,1105
< standardized by the C language. Under UNIX, use ioctl to play with
< the terminal driver modes.
---
> standardized by the C language. If you are using curses, use its
> cbreak() function. Under UNIX, use ioctl to play with the terminal
> driver modes (CBREAK or RAW under "classic" versions; ICANON,
> c_cc[VMIN] and c_cc[VTIME] under System V or Posix systems).
1074,1075c1117,1119
< your operating system, you may be able to use "nonblocking I/O", or
< a system call named "select", or the FIONREAD ioctl.
---
> your system, you may be able to use "nonblocking I/O", or a system
> call named "select", or the FIONREAD ioctl, or O_NDELAY, or a
> kbhit() routine.
1090c1134,1137
< changed, a special-case scheme can be set up.
---
> changed, a special-case scheme can be set up. (Under Unix, a child
> process cannot directly affect its parent at all. Other operating
> systems have different process environments which could
> intrinsically support such communication.)
1117a1164,1191
> 51. When I read from the keyboard with scanf(), it seems to hang until I
> type one extra line of input.
>
> A: scanf() was designed for free-format input, which is seldom what you
> want when reading from the keyboard. In particular, "\n" in a
> format string does not mean "expect a newline", it means "discard
> all whitespace". But the only way to discard all whitespace is to
> continue reading the stream until a non-whitespace character is seen
> (which is then left in the buffer for the next input), so the effect
> is that it keeps going until it sees a nonblank line.
>
> 52. So what should I use instead?
>
> A: You could use a "%c" format, which will read one character that you
> can then manually compare against a newline; or "%*c" and no
> variable if you're willing to trust the user to hit a newline; or
> "%*[^\n]%*c" to discard everything up to and including the newline.
> Or you could use fgets() to read a whole line, and then use sscanf()
> or other string functions to parse the line buffer.
>
> 53. Can someone tell me how to write itoa (the inverse of atoi)?
>
> A: Just use sprintf.
1137c1212
< your compiler, operating system, and processer can be supplied. You
---
> your compiler, operating system, and processor can be supplied. You
1148,1149c1223,1224
< p2c written by Dave Gillespie, and posted to comp.sources.unix in
< March, 1990.
---
> p2c written by Dave Gillespie, and posted to
> comp.sources.unix in March, 1990 (Volume 21).
1151,1152c1226,1228
< ptoc another comp.sources.unix contribution, this one written in
< Pascal.
---
> ptoc another comp.sources.unix contribution, this one
> written in Pascal (comp.sources.unix, Volume 10, also
> patches in Volume 13?).
1157a1235,1246
> FOR_C Available from:
>
> Cobalt Blue
> 2940 Union Ave., Suite C
> San Jose, CA 95124
> (408) 723-0474
>
> Promula.Fortran Available from
>
> Promula Development Corp.
> 3620 N. High St., Suite 301
> Columbus, OH 43214
> (614) 263-5454
>
1162a1250,1251
> 57. How can I call Fortran (BASIC, Pascal, ADA, LISP) functions from C?
> (And vice versa?)
>
> A: The answer is entirely dependent on the machine and the specific
> calling sequences of the various compilers in use, and may not be
> possible at all. Read your compiler documentation very carefully;
> sometimes there is a "mixed-language programming guide," although
> the techniques for passing arguments correctly are often arcane.
1166,1168c1259
< A: C comments do not nest. For this reason, it is usually better to
< "comment out" large sections of code, which might contain comments,
< with #ifdef.
---
> A: Nested comments would cause more harm than good, mostly because of
> the possibility of accidentally leaving comments unclosed by
> including the characters "/*" within them. For this reason, it is
> usually better to "comment out" large sections of code, which might
> contain comments, with #ifdef or #if 0.
1181,1182c1278,1279
< floating-point versions of printf and scanf do not handle %e, %f,
< and %g. Occasionally the heuristics for "is the program using
---
> floating-point versions of printf and scanf save space by not
> including code to handle %e, %f, and %g. Occasionally the
1196c1294,1295
< A: Plum Hall, among others, sells one.
---
> A: Plum Hall, (1 Spruce Ave., Cardiff, NJ 08232, USA), among others,
> sells one.
1198a1297,1303
> 61. Where can I get a YACC grammar for C?
>
> A: Several grammars are floating around; keep your eyes open. There is
> one on uunet.uu.net (192.48.96.2) in net.sources/ansi.c.grammar.Z .
> FSF's GNU C compiler contains a grammar, as does the appendix to
> K&R II. Several have recently been posted to the net.
1217c1304
< 57. Where can I get the "Indian Hills Style Guide" and other coding
---
> 62. Where can I get the "Indian Hill Style Guide" and other coding
1220a1307,1315
> A: Various standards are available for anonymous ftp from:
>
> site file/directory
>
> cs.washington.edu ~ftp/pub/cstyle.tar.Z
> (128.95.1.4)
>
> cs.toronto.edu doc/programming
>
> giza.cis.ohio-state.edu pub/style-guide
>
> prep.ai.mit.edu pub/gnu/standards.text
1234a1320,1325
> 63. Where can I get extra copies of this list?
>
> A: For now, just pull it off the net; it is normally posted on about
> the first of the month, with an Expiration: line which should keep
> it around all month. Eventually, it may be available for anonymous
> ftp, or via a mailserver.
1238,1240c1329,1332
< Dunn, Tony Hansen, Blair Houghton, Kirk Johnson, Andrew Koenig, John
< Lauro, Christopher Lott, Rich Salz, and Joshua Simons, who have
< contributed, directly or indirectly, to this article.
---
> Dunn, Tony Hansen, Guy Harris, Karl Heuer, Blair Houghton, Kirk Johnson,
> Andrew Koenig, John Lauro, Christopher Lott, Rich Salz, Joshua Simons,
> and Erik Talvola, who have contributed, directly or indirectly, to this
> article.
More information about the Comp.lang.c
mailing list