Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!adam!scs From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Changes to Answers to Frequently Asked Questions (FAQ) on comp.lang.c Message-ID: <1990Jul18.034743.22366@athena.mit.edu> Date: 18 Jul 90 03:47:43 GMT Sender: daemon@athena.mit.edu (Mr Background) Reply-To: scs@adam.mit.edu (Steve Summit) Organization: Thermal Technologies, Inc. Lines: 433 (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.