Changes to Answers to Frequently Asked Questions (FAQ) on comp.lang.c
Steve Summit
scs at adam.mit.edu
Tue Jan 1 15:59:33 AEST 1991
This article contains changes between the previous posting of
the frequently-asked questions list (November 1) and the new one.
(Do _not_ worry if you have not seen the new one yet; it's coming
up next.)
(These diffs have been edited for readability and are not suitable
for the patch program.)
==========
< [Last modified 11/30/90 by scs.]
---
> [Last modified December 16, 1990 by scs.]
==========
< multidimensional arrays, if at all. (See question 18 above.) When
< people say "pointer to array" casually, they usually mean "pointer
< to array's first element," which is the more useful type.
---
> multidimensional arrays, if at all. (See question 18 above.) When
> people speak casually of a pointer to an array, they usually mean a
> pointer to its first element; the type of this latter pointer is
> generally more useful.
==========
< The behavior of code which contains such ambiguous or undefined side
< effects has always been undefined. Don't even try to find out how
---
> The behavior of code which contains ambiguous or undefined side
> effects has always been undefined. (Note, too, that a compiler's
> choice, especially under ANSI rules, for "undefined behavior" may be
> to refuse to compile the code.) Don't even try to find out how your
==========
> The published Standard includes a "Rationale," which explains many
> of its decisions, and discusses a number of subtle points, including
> several of those covered here. (The Rationale is "not part of ANSI
> Standard X3.159-1989, but is included for information only.")
>
> The Standard has also been adopted as ISO/IEC 9899:1990, although
> the Rationale is currently not included.
==========
< A: The main problem is older linkers which are neither under the
---
> A: The problem is older linkers which are neither under the control of
==========
< appearance of more significance in external identifiers, read the
< excellently-worded X3.159 Rationale, which discusses several such
< schemes and describes why they can't be mandated.
---
> appearance of more significance in external identifiers, read the
> excellently-worded X3.159 Rationale, (see question 24) which
> discusses several such schemes and explains why they couldn't be
> mandated.
==========
< call it with a double set of parentheses, which appear to the
< compiler to indicate a single argument:
---
> call it with a double set of parentheses, which appear to the
> preprocessor to indicate a single argument:
==========
< #include <stdio.h>
< main()
< {
< char answer[100];
< printf("Type something:\n");
< fgets(answer, 100, stdin);
< printf("You typed \"%s\"\n", answer);
< }
---
> #include <stdio.h>
> #include <string.h>
> main()
> {
> char answer[100], *p;
> printf("Type something:\n");
> fgets(answer, 100, stdin);
> if((p = strchr(answer, '\n')) != NULL)
> *p = '\0';
> printf("You typed \"%s\"\n", answer);
> }
==========
< overly-long line. (Unfortunately, gets and fgets differ in their
< treatment of the trailing \n.) It would also be possible to use
---
> overly-long line. (Unfortunately, fgets does not automatically
> delete the trailing \n, as gets would.) It would also be possible
==========
< Q: But the man page for strcat said that it took two char *'s as
< arguments. How was I supposed to know to allocate things?
---
> 40. But the man page for strcat says that it takes two char *'s as
> arguments. How am I supposed to know to allocate things?
==========
< A: In general, when using pointers you _always_ have to worry about
< memory allocation, at least to make sure that the compiler is doing
---
> 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
==========
< The Synopsis section at the top of a Unix-style man page is often
< misleading. The code fragments presented there are closer to the
---
> The Synopsis section at the top of a Unix-style man page can be
> misleading. The code fragments presented there are closer to the
==========
< disallows it, but it is hard to imagine a compiler or architecture
< for which it wouldn't work.
---
> disallows it, but it is hard to imagine a compiler or architecture
> for which it wouldn't work. (Debugging, array-bounds-checking
> compilers might issue warnings.)
==========
< 54. I've seen different methods used for calling through functions to
< pointers. Wht's the story?
---
> 55. I've seen different methods used for calling through pointers to
> functions. What's the story?
==========
< Another argument says that functions are always called through
< pointers, but that "real" functions decay implicitly into pointers
< and so cause no trouble. This argument, which was adopted by the
< ANSI standard, means that
---
> Another analysis holds that functions are always called through
> pointers, but that "real" functions decay implicitly into pointers
> (in expressions, as they do in initializations) and so cause no
> trouble. This reasoning, which was adopted in the ANSI standard,
==========
< is legal and works correctly (it has always been unambiguous;
< there's nothing you ever could have done with a function pointer
< except call through it). The explicit * is harmless, and still
< allowed (and recommended, if portability to older compilers is
---
> is legal and works correctly, whether fp is a function or a pointer
> to one. (The usage has always been unambiguous; there is nothing
> you ever could have done with a function pointer followed by an
> argument list except call through it). An explicit * is harmless,
> and still allowed (and recommended, if portability to older
==========
< may also be able to use "nonblocking I/O", or a system call named
< "select", or the FIONREAD ioctl, or O_NDELAY, or a kbhit() routine.
---
> may also be able to use "nonblocking I/O", or a system call named
> "select", or the FIONREAD ioctl, or the O_NDELAY option to open() or
> fcntl(), or a kbhit() routine.
==========
< A: BSD systems provide ftruncate(), and some MS-DOS compilers supply
< chsize(), but there is no portable solution.
---
> A: BSD systems provide ftruncate(), and some PC compilers supply
> chsize(), but there is no portable solution.
==========
< with fprintf and read with fscanf or the like. Be very skeptical of
< arguments that text files are too big, or that reading and writing
< them is too slow. Not only is their efficiency frequently adequate
---
> with fprintf and read with fscanf or the like. Be very skeptical of
> arguments which imply that text files are too big, or that reading
> and writing them is too slow. Not only is their efficiency
> frequently acceptable in practice, but the advantages of being able
==========
< perhaps take advantage of prewritten I/O libraries, by making use of
< standardized formats such as Sun's XDR or OSI's ASN.1 .
---
> perhaps take advantage of prewritten I/O libraries, by making use of
> standardized formats such as Sun's XDR, OSI's ASN.1, or CCITT's
> X.409 .
==========
< central, public-spirited site, such as uunet.uu.net. However, this
< article cannot track or list all of the available sites and how to
< access them.
---
> central, public-spirited site, such as uunet.uu.net. However, this
> article cannot track or list all of the available archive sites and
> how to access them. The comp.archives newsgroup contains numerous
> announcements of anonymous ftp availability of various items.
==========
< Among other things, the associative and distributive laws do not
< hold exactly (that is, order of calculation may be important, and
< repeated addition is not necessarily equivalent to multiplication).
---
> Among other things, the associative and distributive laws do not
> hold completely (i.e. order of operation may be important, repeated
> addition is not necessarily equivalent to multiplication, and
> underflow or cumulative precision loss is often a problem).
==========
< especially don't assume that floating-point values can be compared
< for equality. (Don't stick random "fuzz factors" in, either.)
---
> especially don't assume that floating-point values can be compared
> for equality. (Don't stick in random "fuzz factors," either.)
==========
< These problems are no worse for C than they are for any other
< language. Languages usually define floating-point semantics as
< "however the processor does them;" otherwise a compiler for a
---
> These problems are no worse for C than they are for any other
> computer language. Floating-point semantics are usually defined as
> "however the processor does them;" otherwise a compiler for a
==========
< If your coding environment (i.e. co-workers or company policy) does
< not suggest a style, and you don't feel like inventing your own,
< just copy K&R. (The tradeoffs between various indenting and brace
< placement options can be exhaustively and minutely examined, but
< don't warrant repetition here.)
---
> If your coding environment (i.e. local custom or company policy)
> does not suggest a style, and you don't feel like inventing your
> own, just copy K&R. (The tradeoffs between various indenting and
> brace placement options can be exhaustively and minutely examined,
> but don't warrant repetition here. See also the Indian Hill Style
> Guide.)
==========
< A: Various standards are available for anonymous ftp from:
---
> A: Various documents are available for anonymous ftp from:
==========
< A: You can make "char" rhyme with "far" or "bear;" the choice is
< arbitrary. Bell Labs once proposed the (now obsolete) term
---
> A: You can pronounce the C keyword "char" like the English words
> "char," "care," or "car;" the choice is arbitrary. Bell Labs once
==========
> Thanks to Sudheer Apte, Mark Brader, Joe Buehler, Raymond Chen,
> Christopher Calabrese, Norm Diamond, Ray Dunn, Stephen M. Dunn, Bjorn
> Engsig, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Karl Heuer,
> Blair Houghton, Kirk Johnson, Andrew Koenig, John Lauro, Christopher
> Lott, Evan Manning, Mark Moraes, Francois Pinard, randall at virginia, Rich
> Salz, Paul Sand, Patricia Shanahan, Joshua Simons, Henry Spencer, Erik
> Talvola, Clarke Thatcher, Chris Torek, Ed Vielmetti, and Freek Wiedijk,
> 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
More information about the Comp.lang.c
mailing list