Section 16. Strange Problems

16.1b:  I'm getting baffling syntax errors which make no sense at all,
	and it seems like large chunks of my program aren't being
	compiled.

A:      Check for unclosed comments or mismatched #if/#ifdef/#ifndef/
	#else/#endif directives; remember to check header files, too.
	(See also questions 2.18, 10.9, and 11.29.)

16.1c:  Why isn't my procedure call working?  The compiler seems to skip
	right over it.

A:      Does the code look like this?

		myprocedure;

	C has only functions, and function calls always require
	parenthesized argument lists, even if empty.  Use

		myprocedure();

16.3:   This program crashes before it even runs!  (When single-stepping
	with a debugger, it dies before the first statement in main().)

A:      You probably have one or more very large (kilobyte or more)
	local arrays.  Many systems have fixed-size stacks, and those
	which perform dynamic stack allocation automatically (e.g. Unix)
	can be confused when the stack tries to grow by a huge chunk all
	at once.  It is often better to declare large arrays with static
	duration (unless of course you need a fresh set with each
	recursive call, in which case you could dynamically allocate
	them with malloc(); see also question 1.31).

	(See also questions 11.12b, 16.4, 16.5, and 18.4.)

16.4:   I have a program that seems to run correctly, but it crashes as
	it's exiting, *after* the last statement in main().  What could
	be causing this?

A:      Look for a misdeclared main() (see questions 2.18 and 10.9), or
	local buffers passed to setbuf() or setvbuf(), or problems in
	cleanup functions registered by atexit().  See also questions
	7.5a and 11.16.

	References: CT&P Sec. 5.3 pp. 72-3.

16.5:   This program runs perfectly on one machine, but I get weird
	results on another.  Stranger still, adding or removing a
	debugging printout changes the symptoms...

A:      Lots of things could be going wrong; here are a few of the more
	common things to check:

		uninitialized local variables (see also question 7.1)

		integer overflow, especially on 16-bit machines,
		especially of an intermediate result when doing things
		like a * b / c (see also question 3.14)

		undefined evaluation order (see questions 3.1 through 3.4)

		omitted declaration of external functions, especially
		those which return something other than int, or have
		"narrow" or variable arguments (see questions 1.25, 11.3,
		14.2, and 15.1)

		dereferenced null pointers (see section 5)

		improper malloc/free use: assuming malloc'ed memory
		contains 0, assuming freed storage persists, freeing
		something twice, corrupting the malloc arena (see also
		questions 7.19 and 7.20)

		pointer problems in general (see also question 16.8)

		mismatch between printf() format and arguments, especially
		trying to print long ints using %d (see question 12.9)

		trying to allocate more memory than an unsigned int can
		count, especially on machines with limited memory (see
		also questions 7.16 and 19.23)

		array bounds problems, especially of small, temporary
		buffers, perhaps used for constructing strings with
		sprintf() (see also questions 7.1 and 12.21)

		invalid assumptions about the mapping of typedefs,
		especially size_t

		floating point problems (see questions 14.1 and 14.4)

		anything you thought was a clever exploitation of the way
		you believe code is generated for your specific system

	Proper use of function prototypes can catch several of these
	problems; lint would catch several more.  See also questions
	16.3, 16.4, and 18.4.

16.6:   Why does this code:

		char *p = "hello, world!";
		p[0] = 'H';

	crash?

A:      String literals are not necessarily modifiable, except (in
	effect) when they are used as array initializers.  Try

		char a[] = "hello, world!";

	See also question 1.32.

	References: ISO Sec. 6.1.4; H&S Sec. 2.7.4 pp. 31-2.

16.8:   What do "Segmentation violation" and "Bus error" mean?

A:      These generally mean that your program tried to access memory it
	shouldn't have, invariably as a result of stack corruption or
	improper pointer use.  Likely causes are overflow of local
	("automatic," stack-allocated) arrays; inadvertent use of null
	pointers (see also questions 5.2 and 5.20) or uninitialized,
	misaligned, or otherwise improperly allocated pointers (see
	questions 7.1 and 7.2); corruption of the malloc arena (see
	question 7.19); and mismatched function arguments, especially
	involving pointers; two possibilities are scanf() (see question
	12.12) and fprintf() (make sure it receives its first FILE *
	argument).

	See also questions 16.3 and 16.4.