[sdiy] C coding

[Cornutt, David K]

Sorry, folks, but I have to get my licks in too.  If we
can have religious wars over what kinds of opamps to use,
then we can have them over software issues too...


From: Michael E. Caloroso [mailto:analoguediehard at att.net]
> goto statements can take you *outside* the function.  Do this and now 
> you have pointers in the stack that are invalid.  

First of all, I've never seen a compiler that allowed
a goto to jump out of a function.  I suppose it's possible,
but such a compiler would violate all kinds of assumptions
about the scope of labels, which would impact switch
statements too.  I would classify such a compiler as not
just non-conforming, but broken.  

Now the C longjmp can definitely take you out of the function,
but that isn't the same thing and it doesn't work the same way.
Even in the case of a longjmp, the stack should (if the compiler
isn't broken) unwind cleanly to the point of the preceding
setjmp.  This can result in pointers becoming invalid.  But
in C, *any* function return can invalidate a pointer if the
pointer was set to the address of an auto variable within
that function.  Here's a function that creates a pointer
which becomes invalid the moment the function returns:

int *f (void)
{
	int i;
	return &i;
}

> This fragments the 
> stack, raising the spectre of stack overflow and a system crash. 
> Framented memory is the bane of code that runs 24/7.

Indeed, but I've never heard of fragmenting a stack.  Fragmenting
a heap, yes, but stacks do not fragment by definition (unless the
compiler is really screwy, or just plain broken).  If the stack
is of reasonable size, and the called functions aren't doing
ridiculous things like declaring 100-Mbyte arrays auto (which
many compilers won't allow anyway), then the only to overflow
a stack is infinite recursion.  Other than that, I can call and
return from functions all day and the stack usage will never
exceed a certain high-water mark.

> 
> I have done plenty of code optimization of legacy code.  Fragmented 
> memory is one of the worse offenders and is a topic that too few 
> developers are aware of.  

Absolutely.  But that's heap abuse (not even fragmentation,
really, just memory consumption caused by allocating memory and
never releasing it), and it's nearly always caused by a 
programmer who gets careless with malloc.  That's got nothing
to do with stacks or function calls.  
 
> If I ever set foot on a plane that contains some of my 
> design, you better believe I went the extra mile to confirm 
> reliability 
> as the last place to encounter stack overflow/system crash is at 
> 30,000ft above ground.  That's what is so freaking horrible 
> about a goto 
> statement.

I challenge you to produce any example of any code ever
written (assuming an ANSI-conformant compiler) where a goto
directly caused a stack overflow.  I've written code for
systems that flew on the Space Shuttle that had a few gotos
in it, and there were no problems.