[lug] C programming Q.

rm at fabula.de rm at fabula.de
Thu Apr 18 07:27:43 MDT 2002


On Wed, Apr 17, 2002 at 01:59:59PM -0500, Michael J. Hammel wrote:
> Thus spoke rm at fabula.de
> > No, this is a _good_ habbit, really ;-) Since i made this the default
> > in my projects (and cranked up the warning switches) i had way less 
> > bugs sneak into my production code.
> 
> It's good if you're just learning programming, perhaps.  Mostly, it gets in
> my way.  

Sorry, but i can't agree. If you aren't a novice then of course you don't introduce
any prototype missmatches and hence get no warnings ;-) But serious: a prototype
missmatch _is_ a bug, maybe not one that is still present in the machine instructions,
but definitely in the samantics of your code.
 
> So far, I've only found one real bug in the code (written by
> someone who obviously thinks in objects).  The majority have been prototype
> mismatches.  How often does a missing prototype cause serious problems on a
> given system (ignoring portability for the time being)?

Depends on what actually was the rationale for writing the prototype the way
it's written. If i write a prototype 'int f(void)' i'm talking about a function
(procudure) that expects _no_ parameters. This means that there are _no_ arguments
on the stack at invocation time. And yes, the position of the stack pointer
can be relevant - there's something like inline assembler in gcc. 

> Not that it matters much to me either way.  Fixing these is easy for the
> most part.  It just delays me from spending time doing real development.
> 
> > Well, a pointer to 'int f(uint *val1, uint *val2, uint count);' _is_ different
> > from a pointer to 'int f(void)'. 
> 
> But how often does this cause a serious run time error?  Changing it is
> easy of course.  I've had so few problems not specifying *any* arguments
> in prototypes that this issue seems like busy work more than better coding.

Oh, but that's completely differnet: 

 int f(void) =/= int f()

One is a function that takes _no_ arguments, the other is a function that
the compiler has no idea about the arguments. The later is pre-ansii code
and is tolerated by many compilers but nevertheless should be avoided for
new programs.

Ralf



More information about the LUG mailing list