[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