Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

Archive-name: C-faq/diff
Comp-lang-c-archive-name: C-FAQ-list.diff
URL: http://www.eskimo.com/~scs/C-faq/top.html

This article is a repost of the differences between the previous
version of the comp.lang.c FAQ list (version 3.4, last modified
September 5, 1996, last posted January 1, 1999) and the current
one (version 3.4, first posted February 7, 1999).  These diffs
have been heavily edited, for readability's sake, and are not
suitable as input to a patch program.

I must beg a number of peoples' pardons by confessing that, once
again, I have not managed to acknowledge all of the suggestions
in the current pile.  Apologies to those of you who have still
not heard from me or seen your suggestion used here, even after
many months.

Note also that, as of this writing, these changes have *not*
yet been incorporated into the HTML version of the FAQ list at
http://www.eskimo.com/~scs/C-faq/top.html .

(For those not familiar with "diff" notation, in the lines that
follow, a '<' character indicates old, changed, or deleted text,
and a '>' character indicates new text.)

First, the new entries:

==========
> 3.3b:	Here's a slick expression:
>
>		a ^= b ^= a ^= b
>
>	It swaps a and b without using a temporary.
>
> A:	Not portably, it doesn't.  It attempts to modify the variable a
>	twice between sequence points, so its behavior is undefined.
>
>	For example, it has been reported that when given the code
>
>		int a = 123, b = 7654;
>		a ^= b ^= a ^= b;
>
>	the SCO Optimizing C compiler (icc) sets b to 123 and a to 0.
>
>	See also questions 3.1, 3.8, 10.3, and 20.15c.
==========
> 7.3b:	I just tried the code
>
>		char *p;
>		strcpy(p, "abc");
>
>	and it worked.  How?  Why didn't it crash?
>
> A:	You got lucky, I guess.  The memory pointed to by the
>	unitialized pointer p happened to be writable by you,
>	and apparently was not already in use for anything vital.
==========
> 7.3c:	How much memory does a pointer variable allocate?
>
> A:	That's a pretty misleading question.  When you declare
>	a pointer variable, as in
>
>		char *p;
>
>	you (or, more properly, the compiler) have allocated only enough
>	memory to hold the pointer itself; that is, in this case you
>	have allocated sizeof(char *) bytes of memory.  But you have
>	not yet allocated *any* memory for the pointer to point to.
>	See also questions 7.1 and 7.2.
==========
> 11.12a: What's the correct declaration of main()?
>
> A:	Either int main(), int main(void), or int main(int argc,
>	char *argv[]) (with alternate spellings of argc and *argv[]
>	obviously allowed).  See also questions 11.12b to 11.15 below.
>
>	References: ISO Sec. 5.1.2.2.1, Sec. G.5.1; H&S Sec. 20.1 p.
>	416; CT&P Sec. 3.10 pp. 50-51.
==========
> 12.9b:  What printf format should I use for a typedef like size_t
>	when I don't know whether it's long or some other type?
>
> A:	Use a cast to convert the value to a known, conservatively-
>	sized type, then use the printf format matching that type.
>	For example, to print the size of a type, you might use
>
>		printf("%lu", (unsigned long)sizeof(thetype));
==========
> 12.36b: How can I arrange to have output go two places at once,
>	e.g. to the screen and to a file?
>
> A:	You can't do this directly, but you could write your
>	own printf variant which printed everything twice.
>	See question 15.5.
==========
> 13.14b: Does C have any Year 2000 problems?
>
> A:	No, although poorly-written C programs do.
>
>	The tm_year field of struct tm holds the value of the year minus
>	1900; this field will therefore contain the value 100 for the
>	year 2000.  Code that uses tm_year correctly (by adding or
>	subtracting 1900 when converting to or from human-readable
>	4-digit year representations) will have no problems at the turn
>	of the millennium.  Any code that uses tm_year incorrectly,
>	however, such as by using it directly as a human-readable
>	2-digit year, or setting it from a 4-digit year with code like
>
>		tm.tm_year = yyyy % 100;	/* WRONG */
>
>	or printing it as an allegedly human-readable 4-digit year with
>	code like
>
>		printf("19%d", tm.tm_year);	/* WRONG */
>
>	will have grave y2k problems indeed.  See also question 20.32.
>
>	References: K&R2 Sec. B10 p. 255; ISO Sec. 7.12.1; H&S Sec. 18.4
>	p. 401.
==========
> 18.13b: Is there an on-line C reference manual?
>
> A:	Two possibilities are
>	http://www.cs.man.ac.uk/standard_c/_index.html and
>	http://www.dinkumware.com/htm_cl/index.html .
==========
> 18.15d: I need code for performing multiple precision arithmetic.
>
> A:	Some popular packages are the "quad" functions within the BSD
>	Unix libc sources (ftp.uu.net, /systems/unix/bsd-sources/..../
>	/src/lib/libc/quad/*), the GNU MP library, the MIRACL package
>	(see http://indigo.ie/~mscott/ ), and the old Unix libmp.a.
>	See also questions 14.12 and 18.16.
>
>	References: Schumacher, ed., _Software Solutions in C_ Sec. 17
>	pp. 343-454.
==========
> 19.16b: How do I copy files?
>
> A:	Either use system() to invoke your operating system's copy
>	utility (see question 19.27), or open the source and destination
>	files (using fopen() or some lower-level file-opening system call),
>	read characters or blocks of characters from the source file,
>	and write them to the destination file.
>
>	References: K&R Sec. 1, Sec. 7.
==========
> 19.40c: I'm trying to compile this program, but the compiler is
>	complaining that "union REGS" is undefined, and the linker
>	is complaining that int86() is undefined.
>
> A:	Those have to do with MS-DOS interrupt programming.  They don't
>	exist on other systems.
==========
> 20.15b: People claim that optimizing compilers are good and that we no
>	longer have to write things in assembler for speed, but my
>	compiler can't even replace i/=2 with a shift.
>
> A:	Was i signed or unsigned?  If it was signed, a shift is not
>	equivalent (hint: think about the result if i is negative and
>	odd), so the compiler was correct not to use it.
==========
> 20.15c: How can I swap two values without using a temporary?
>
> A:	The standard hoary old assembly language programmer's trick is:
>
>		a ^= b;
>		b ^= a;
>		a ^= b;
>
>	But this sort of code has little place in modern, HLL
>	programming.  Temporary variables are essentially free,
>	and the idiomatic code using three assignments, namely
>
>		int t = a;
>		a = b;
>		b = t;
>
>	is not only clearer to the human reader, it is more likely to be
>	recognized by the compiler and turned into the most-efficient
>	code (e.g. using a swap instruction, if available).  The latter
>	code is obviously also amenable to use with pointers and
>	floating-point values, unlike the XOR trick.  See also questions
>	3.3b and 10.3.
==========
> 20.20b: Is C a great language, or what?  Where else could you write
>	something like a+++++b ?
>
> A:	Well, you can't meaningfully write it in C, either.
>	The rule for lexical analysis is that at each point during a
>	straightforward left-to-right scan, the longest possible token
>	is determined, without regard to whether the resulting sequence
>	of tokens makes sense.  The fragment in the question is
>	therefore interpreted as
>
>		a ++ ++ + b
>
>	and cannot be parsed as a valid expression.
>
>	References: K&R1 Sec. A2 p. 179; K&R2 Sec. A2.1 p. 192; ISO
>	Sec. 6.1; H&S Sec. 2.3 pp. 19-20.
==========
> 20.24b: What is assert() and when would I use it?
>
> A:	It is a macro, defined in , for testing "assertions".
>	An assertion essentially documents an assumption being made by
>	the programmer, an assumption which, if violated, would indicate
>	a serious programming error.  For example, a function which was
>	supposed to be called with a non-null pointer could write
>
>		assert(p != NULL);
>
>	A failed assertion terminates the program.  Assertions should
>	*not* be used to catch expected errors, such as malloc() or
>	fopen() failures.
>
>	References: K&R2 Sec. B6 pp. 253-4; ISO Sec. 7.2; H&S Sec. 19.1
>	p. 406.
==========
> 20.39b: What do "lvalue" and "rvalue" mean?
>
> A:	Simply speaking, an "lvalue" is an expression that could appear
>	on the left-hand sign of an assignment; you can also think of it
>	as denoting an object that has a location.  (But see question
>	6.7 concerning arrays.)  An "rvalue" is any expression that has
>	a value (and that can therefore appear on the right-hand sign of
>	an assignment).
==========


Next, the significant changes:

==========
< 1.4:	What should the 64-bit type on new, 64-bit machines be?
<
< A:	Some vendors of C products for 64-bit machines support 64-bit
<	long ints.  Others fear that too much existing code is written
<	to assume that ints and longs are the same size, or that one or
<	the other of them is exactly 32 bits, and introduce a new,
<	nonstandard, 64-bit long long (or __longlong) type instead.
<
<	Programmers interested in writing portable code should therefore
<	insulate their 64-bit type needs behind appropriate typedefs.
<	Vendors who feel compelled to introduce a new, longer integral
<	type should advertise it as being "at least 64 bits" (which is
<	truly new, a type traditional C does not have), and not "exactly
<	64 bits."
<
<	References: ANSI Sec. F.5.6; ISO Sec. G.5.6.
---
> 1.4:	What should the 64-bit type on a machine that can support it?
>
> A:	The forthcoming revision to the C Standard (C9X) specifies type
>	long long as effectively being at least 64 bits, and this type
>	has been implemented by a number of compilers for some time.
>	(Others have implemented extensions such as __longlong.)
>	On the other hand, there's no theoretical reason why a compiler
>	couldn't implement type short int as 16, int as 32, and long int
>	as 64 bits, and some compilers do indeed choose this
>	arrangement.
>
>	See also question 18.15d.
>
>	References: C9X Sec. 5.2.4.2.1, Sec. 6.1.2.5.
==========
  A:	This technique is popular, although Dennis Ritchie has called it
	"unwarranted chumminess with the C implementation."  An official
	interpretation has deemed that it is not strictly conforming
<	with the C Standard.  (A thorough treatment of the arguments
<	surrounding the legality of the technique is beyond the scope of
<	this list.)  It does seem to be portable to all known
---
>	with the C Standard, although it does seem to work under all
	known implementations.
==========
>	C9X will introduce the concept of a "flexible array member",
>	which will allow the size of an array to be omitted if it is
>	the last member in a structure, thus providing a well-defined
>	solution.
>
>	References: Rationale Sec. 3.5.4.2; C9X Sec. 6.5.2.1.
==========
< A:	C has no way of generating anonymous structure values.  You will
---
> A:	As of this writing, C has no way of generating anonymous
>	structure values.  You will have to use a temporary structure
	variable or a little structure-building function.
==========
<	building function.  (gcc provides structure constants as an
<	extension, and the mechanism will probably be added to a future
<	revision of the C Standard.)  See also question 4.10.
---
>	The C9X Standard will introduce "compound literals"; one form of
>	compound literal will allow structure constants.  For example,
>	to pass a constant coordinate pair to a plotpoint() function
>	which expects a struct point, you will be able to call
>
>		plotpoint((struct point){1, 2});
>
>	Combined with "designated initializers" (another C9X feature),
>	it will also be possible to specify member values by name:
>
>		plotpoint((struct point){.x=1, .y=2});
>
>	See also question 4.10.
>
>	References: C9X Sec. 6.3.2.5, Sec. 6.5.8.
==========
< A:	ANSI Standard C allows an initializer for the first-named member
<	of a union.  There is no standard way of initializing any other
<	member (nor, under a pre-ANSI compiler, is there generally any
<	way of initializing a union at all).
---
> A:	The current C Standard allows an initializer for the first-named
>	member of a union.  C9X will introduce "designated initializers"
>	which can be used to initialize any member.
==========
3.5:	But what about the && and || operators?
	I see code like "while((c = getchar()) != EOF && c != '\n')" ...

< A:	There is a special exception for those operators (as well as the
<	?: and comma operators): left-to-right evaluation is guaranteed
<	(as is an intermediate sequence point, see question 3.8).  Any
<	book on C should make this clear.
---
> A:	There is a special "short-circuiting" exception for those
>	operators.  The right-hand side is not evaluated if the left-
>	hand side determines the outcome (i.e. is true for || or false
>	for &&).  Therefore, left-to-right evaluation is guaranteed, as
>	it also is for the comma operator.  Furthermore, all of these
>	operators (along with ?:) introduce an extra internal sequence
>	point (see question 3.8).
==========
  4.8:	I have a function which accepts, and is supposed to initialize,
	a pointer:

<		void f(ip)
<		int *ip;
---
>		void f(int *ip)
		{
==========
<	also question 15.3.)  It is safest to properly cast all null
<	pointer constants in function calls: to guard against varargs
<	functions or those without prototypes, to allow interim use of
<	non-ANSI compilers, and to demonstrate that you know what you
<	are doing.  (Incidentally, it's also a simpler rule to
<	remember.)
---
>	also question 15.3.)  It is probably safest to properly cast
>	all null pointer constants in function calls, to guard against
>	varargs functions or those without prototypes.
==========
< A:	Follow these two simple rules:
---
> A:	Here are two simple rules you can follow:
==========
	The rest of the discussion has to do with other people's
	misunderstandings, with the internal representation of null
<	pointers (which you shouldn't need to know), and with ANSI C
<	refinements.  Understand questions 5.1, 5.2, and 5.4, and
---
>	pointers (which you shouldn't need to know), and with the
>	complexities of function prototypes.  (Taking those complexities
>	into account, we find that rule 2 is conservative, of course;
>	but it doesn't hurt.)  Understand questions 5.1, 5.2, and 5.4,
==========
<		f(a)
<		char a[];
---
>		void f(char a[])
		{ ... }
==========
<		f(a)
<		char *a;
---
>		void f(char *a)
==========
< A:	You can't, in C.  Array dimensions must be compile-time
<	constants.  (gcc provides parameterized arrays as an extension.)
<	You'll have to use malloc(), and remember to call free() before
---
> A:	Until recently, you couldn't.  Array dimensions in C
>	traditionally had to be compile-time constants.  C9X will
>	introduce variable-length arrays (VLA's) which will solve this
>	problem; local arrays may have sizes set by variables or other
>	expressions, perhaps involving function parameters.  (gcc has
>	provided parameterized arrays as an extension for some time.)
>	If you can't use C9X or gcc, you'll have to use malloc(), and
==========
< A:	It is usually best to allocate an array of pointers, and then
---
> A:	The traditional solution is to allocate an array of pointers,
	and then initialize each pointer to a dynamically-allocated
	"row."  Here is a two-dimensional example:
==========
<		int **array1 = (int **)malloc(nrows * sizeof(int *));
		for(i = 0; i < nrows; i++)
<			array1[i] = (int *)malloc(ncolumns * sizeof(int));
---
>		int **array1 = malloc(nrows * sizeof(int *));
		for(i = 0; i < nrows; i++)
>			array1[i] = malloc(ncolumns * sizeof(int));
==========
<		int **array2 = (int **)malloc(nrows * sizeof(int *));
<		array2[0] = (int *)malloc(nrows * ncolumns * sizeof(int));
---
>		int **array2 = malloc(nrows * sizeof(int *));
>		array2[0] = malloc(nrows * ncolumns * sizeof(int));
==========
	In either case, the elements of the dynamic array can be
	accessed with normal-looking array subscripts: arrayx[i][j] (for
<	0 <= i < NROWS and 0 <= j < NCOLUMNS).
---
>	0 <= i < nrows and 0 <= j < ncolumns).
==========
<		int *array3 = (int *)malloc(nrows * ncolumns * sizeof(int));
---
>		int *array3 = malloc(nrows * ncolumns * sizeof(int));
==========
<	Finally, you could use pointers to arrays:
---
>	Yet another option is to use pointers to arrays:
==========
		int (*array4)[NCOLUMNS] =
<			(int (*)[NCOLUMNS])malloc(nrows * sizeof(*array4));
---
>		int (*array4)[NCOLUMNS] = malloc(nrows * sizeof(*array4));
==========
>	Finally, in C9X you can use a variable-length array.
==========
>	References: C9X Sec. 6.5.5.2.
==========
<		f(int a[][NCOLUMNS])
---
>		void f(int a[][NCOLUMNS])
==========
<		f(int (*ap)[NCOLUMNS])  /* ap is a pointer to an array */
---
>		void f(int (*ap)[NCOLUMNS])	/* ap is a pointer to an array */
==========
< A:	It's not easy.  One way is to pass in a pointer to the [0][0]
---
> A:	It's not always easy.  One way is to pass in a pointer to the
	[0][0] element, along with the two dimensions, and simulate
	array subscripting "by hand":
==========
<		f2(aryp, nrows, ncolumns)
<		int *aryp;
<		int nrows, ncolumns;
---
>		void f2(int *aryp, int nrows, int ncolumns)
==========
<	gcc allows local arrays to be declared having sizes which are
<	specified by a function's arguments, but this is a nonstandard
<	extension.
---
>	C9X will allow variable-length arrays, and once compilers which
>	accept C9X's extensions become widespread, this will probably
>	become the preferred solution.  (gcc has supported variable-
>	sized arrays for some time.)
==========
<			free(listp);
---
>			free((void *)listp);
==========
< A:	There's no standard way, although it is a common need.  If the
<	compiler documentation is unhelpful, the most expedient way is
---
> A:	There's no standard way, although it is a common need.  gcc
>	provides a -dM option which works with -E, and other compilers
>	may provide something similar.  If the compiler documentation
==========
>	C9X will introduce formal support for function-like macros with
>	variable-length argument lists.  The notation ... will appear at
>	the end of the macro "prototype" (just as it does for varargs
>	functions), and the pseudomacro __VA_ARGS__ in the macro
>	definition will be replaced by the variable arguments during
>	invocation.
==========
>	References: C9X Sec. 6.8.3, Sec. 6.8.3.1.
==========
	More recently, the Standard has been adopted as an international
	standard, ISO/IEC 9899:1990, and this ISO Standard replaces the
	earlier X3.159 even within the United States (where it is known
<	as ANSI/ISO 9899-1990 [1992]).  Its sections are numbered
<	differently (briefly, ISO sections 5 through 7 correspond
<	roughly to the old ANSI sections 2 through 4).  As an ISO
---
>	as ANSI/ISO 9899-1990 [1992]).  As an ISO Standard, it is
	subject to ongoing revision through the release of Technical
	Corrigenda and Normative Addenda.
==========
<	In 1994, Technical Corrigendum 1 amended the Standard in about
<	40 places, most of them minor corrections or clarifications.
<	More recently, Normative Addendum 1 added about 50 pages of new
<	material, mostly specifying new library functions for
<	internationalization.  The production of Technical Corrigenda is
<	an ongoing process, and a second one is expected in late 1995.
<	In addition, both ANSI and ISO require periodic review of their
<	standards.  This process began in 1995, and will likely result
<	in a completely revised standard (nicknamed "C9X" on the
<	assumption of completion by 1999).
---
>	In 1994, Technical Corrigendum 1 (TC1) amended the Standard
>	in about 40 places, most of them minor corrections or
>	clarifications, and Normative Addendum 1 (NA1) added about 50
>	pages of new material, mostly specifying new library functions
>	for internationalization.  In 1995, TC2 added a few more minor
>	corrections.
>
>	As of this writing, a complete revision of the Standard is in
>	its final stages.  The new Standard is nicknamed "C9X" on the
>	assumption that it will be finished by the end of 1999.  (Many
>	of this article's answers have been updated to reflect new C9X
>	features.)
==========
	including several of those covered here.  (The Rationale was
	"not part of ANSI Standard X3.159-1989, but... included for
<	information only," and is not included with the ISO Standard.)
---
>	information only," and is not included with the ISO Standard.
>	A new one is being prepared for C9X.)
==========
< A:	Doing so is perfectly legal, as long as you're careful (see
<	especially question 11.3).  Note however that old-style syntax
---
> A:	Doing so is legal, but requires a certain amount of care (see
>	especially question 11.3).  Modern practice, however, is to
>	use the prototyped form in both declarations and definitions.
>	(The old-style syntax is marked as obsolescent, so official
	support for it may be removed some day.)
==========
<		extern f(struct x *p);
---
>		extern int f(struct x *p);
==========
  11.9:	What's the difference between "const char *p" and
	"char * const p"?

< A:	"char const *p" declares a pointer to a constant character (you
---
> A:	"const char *p" (which can also be written "char const *p")
	declares a pointer to a constant character (you can't change
	the character); "char * const p" declares a constant pointer
	to a (variable) character (i.e. you can't change the pointer).
==========
>	It has been reported that programs using void main() and
>	compiled using BC++ 4.5 can crash.  Some compilers (including
>	DEC C V4.1 and gcc with certain warnings enabled) will complain
>	about void main().
==========
	the systems which have them.  The limitation is only that
	identifiers be *significant* in the first six characters, not
	that they be restricted to six characters in length.  This
<	limitation is annoying, but certainly not unbearable, and is
<	marked in the Standard as "obsolescent," i.e. a future revision
<	will likely relax it.
<
<	This concession to current, restrictive linkers really had to be
<	made, no matter how vehemently some people oppose it.  (The
<	Rationale notes that its retention was "most painful.")  If you
<	disagree, or have thought of a trick by which a compiler
<	burdened with a restrictive linker could present the C
<	programmer with the appearance of more significance in external
<	identifiers, read the excellently-worded section 3.1.2 in the
<	X3.159 Rationale (see question 11.1), which discusses several
<	such schemes and explains why they could not be mandated.
---
>	limitation is marked in the Standard as "obsolescent", and will
>	be removed in C9X.
==========
<	Finally, are you sure you really need to convert lots of old
<	code to ANSI C?  The old-style function syntax is still
<	acceptable (except for variadic functions; see section 15), and
<	a hasty conversion can easily introduce bugs.  (See question
<	11.3.)
==========
< A:	There are not (yet) any good answers to either of these
<	excellent questions, and this represents perhaps the biggest
<	deficiency in the traditional stdio library.
==========
<	12.10).  Several stdio's (including GNU and 4.4bsd) provide the
<	obvious snprintf() function, which can be used like this:
---
>	The "obvious" solution to the overflow problem is a length-
>	limited version of sprintf(), namely snprintf().  It would be
	used like this:
==========
<	and we can hope that a future revision of the ANSI/ISO C
<	Standard will include this function.
---
>	snprintf() has been available in several stdio libraries
>	(including GNU and 4.4bsd) for several years.  It will be
>	standardized in C9X.
==========
>	When the C9X snprintf() arrives, it will also be possible to use
>	it to predict the size required for an arbitrary sprintf() call.
>	C9X snprintf() will return the number of characters it would
>	have placed in the buffer, not just how many it did place.
>	Furthermore, it may be called with a buffer size of 0 and a
>	null pointer as the destination buffer.  Therefore, the call
>
>		nch = snprintf(NULL, 0, fmtstring, /* other arguments */ );
>
>	will compute the number of characters required for the fully-
>	formatted string.
>
>	References: C9X Sec. 7.13.6.6.
==========
A:	ftell() and fseek() use type long int to represent offsets
<	(positions) in a file, and are therefore limited to offsets of
---
>	(positions) in a file, and may therefore be limited to offsets
	of about 2 billion (2**31-1).  The newer fgetpos() and fsetpos()
==========
>	fgetpos() and fsetpos() also record the state associated with
>	multibyte streams.
==========
>	It is barely possible to save away information about a stream
>	before calling freopen(), such that the original stream can
>	later be restored, but the methods involve system-specific calls
>	such as dup(), or copying or inspecting the contents of a FILE
>	structure, which is exceedingly nonportable and unreliable.
==========
<		main()
---
>		int main()
==========
< A:	Here is one method, by Box and Muller, and recommended by Knuth:
---
> A:	Here is one method, recommended by Knuth and due originally to
>	Marsaglia:
==========
<	References: Knuth Sec. 3.4.1 p. 117; Box and Muller, "A Note on
<	the Generation of Random Normal Deviates";
---
>	References: Knuth Sec. 3.4.1 p. 117; Marsaglia and Bray,
>	"A Convenient Method for Generating Normal Variables";
==========
>	C9X will provide isnan(), fpclassify(), and several other
>	classification routines.
==========
>	References: C9X Sec. 7.7.3.
==========
  A:	It is straightforward to define a simple structure and some
<	arithmetic functions to manipulate them.  See also questions
---
>	arithmetic functions to manipulate them.  C9X will support
>	complex as a standard type.  See also questions 2.7, 2.10, and
==========
>	References: C9X Sec. 6.1.2.5, Sec. 7.8.
==========
< A:	Unfortunately, vscanf and the like are not standard.  You're on
<	your own.
---
> A:	C9X will support vscanf(), vfscanf(), and vsscanf().
>	(Until then, you may be on your own.)
==========
>	References: C9X Secs. 7.3.6.12-14.
==========
>	Tom Torfs has a nice tutorial at
>	http://members.xoom.com/tomtorfs/cintro.html .
==========
>	Many comp.lang.c regulars recommend _C: A Modern Approach_,
>	by K.N. King.
==========
>	Scott McMahon has a nice set of reviews at
>	http://www.skwc.com/essent/cyberreviews.html .
==========
  A:	Once upon a time, Unix had a fairly nice little set of device-
<	independent plot routines described in plot(3) and plot(5), but
<	they've largely fallen into disuse.
---
>	independent plot functions described in plot(3) and plot(5).
>	The GNU libplot package maintains the same spirit and supports
>	many modern plot devices;
>	see http://www.gnu.org/software/plotutils/plotutils.html .
==========
	solution is simply to rewrite the file.  (Instead of deleting
	records, you might consider simply marking them as deleted, to
<	avoid rewriting.)  See also questions 12.30 and 19.13.
---
>	avoid rewriting.)  Another possibility, of course, is to use a
>	database instead of a flat file.  See also questions 12.30 and
==========
	to allocate huge amounts of it contiguously.  (The C Standard
<	does not guarantee that single objects can be 32K or larger.)
---
>	does not guarantee that single objects can be 32K or larger,
>	or 64K for C9X.)
==========
	and W. R. Stevens's _UNIX Network Programming_.  (There is also
<	plenty of information out on the net itself.)
---
>	plenty of information out on the net itself, including the
>	"Unix Socket FAQ" at http://kipper.york.ac.uk/~vic/sock-faq/ .)
==========
<		dayofweek(y, m, d)	/* 0 = Sunday */
<		int y, m, d;		/* 1 <= m <= 12, y > 1752 or so */
---
>		int dayofweek(int y, int m, int d)	/* 0 = Sunday */
==========
< A:	The contest schedule is tied to the dates of the USENIX
<	conferences at which the winners are announced.  At the time of
<	this writing, it is expected that the yearly contest will open
<	in October.  To obtain a current copy of the rules and
<	guidelines, send e-mail with the Subject: line "send rules" to:
<
<		{apple,pyramid,sun,uunet}!hoptoad!judges  or
<		judges@toad.com
<
<	(Note that these are *not* the addresses for submitting
<	entries.)
---
> A:	The contest is in a state of flux; see
>	http://www.ioccc.org/index.html for current details.
==========
<	Contest winners should be announced at the USENIX conference in
<	January, and are posted to the net sometime thereafter.  Winning
---
>	Contest winners are usually announced at a Usenix conference,
	and are posted to the net sometime thereafter.  Winning entries
	from previous years (back to 1984) are archived at ftp.uu.net
==========
<	see also http://reality.sgi.com/csp/ioccc/ .
--
>	see also http://www.ioccc.org/index.html .
==========
<	As a last resort, previous winners may be obtained by sending e-
<	mail to the above address, using the Subject: "send YEAR
<	winners", where YEAR is a single four-digit year, a year range,
<	or "all".
		int dayofweek(int y, int m, int d)	/* 0 = Sunday */
==========


Finally, the not-so-significant changes:

==========
< [Last modified September 5, 1996 by scs.]
---
> [Last modified February 7, 1999 by scs.]
==========
< This article is Copyright 1990-1996 by Steve Summit.  Content from the
---
> This article is Copyright 1990-1999 by Steve Summit.  Content from the
==========
  Besides listing frequently-asked questions, this article also summarizes
  frequently-posted answers.  Even if you know all the answers, it's worth
  skimming through this list once in a while, so that when you see one of
  its questions unwittingly posted, you won't have to waste time
> answering.
---
> answering.  (However, this is a large and heavy document, so don't
> assume that everyone on the newsgroup has managed to read all of it in
> detail, and please don't roll it up and thwack people over the head with
> it just because they missed their answer in it.)
==========
< This article was last modified on September 5, 1996, and its travels
< may have taken it far from its original home on Usenet.  It may now
---
> This article was last modified on February 6, 1999, and its travels may
> have taken it far from its original home on Usenet.  It may, however,
  be out-of-date, particularly if you are looking at a printed copy
==========
  retrieved from a tertiary archive site or CD-ROM.  You should be able to
< obtain the most up-to-date copy by anonymous ftp from sites ftp.eskimo.com,
< rtfm.mit.edu, or ftp.uu.net (see questions 18.16 and 20.40), or by
< sending the e-mail message "help" to mail-server@rtfm.mit.edu .
---
> be able to obtain the most up-to-date copy on the web at
> http://www.eskimo.com/~scs/C-faq/top.html or http://www.faqs.org/faqs/ ,
> or from one of the ftp sites mentioned in question 20.40.
==========
  of differences with respect to the previous version.  A hypertext
< version is available on the world-wide web (WWW); see URL
< http://www.eskimo.com/~scs/C-faq/top.html .  Finally, for those who
---
> is available on the web at the aforementioned URL.  Finally, for those
==========
< 1.7:	What's the best way to declare and define global variables?

Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

© allanswers.org | Terms of use