[ On Wednesday, May 26, 1999 at 11:10:50 (+0200), Lennart Augustsson wrote: ]
> Subject: Re: bin/7592: programs' error handle broken by good intentions
>
> "Greg A. Woods" wrote:
> 
> > This is unfortunate because it's still possible to call a function
> > without a prototype declaration in scope (i.e. within the definition of
> > the language), and passing zero as a parameter to such a function
> > expecting a pointer will potentially cause problems because this
> > automatic cast which might in fact widen the representation of zero to
> > something of greater rank than an ordinary 'int' will be missing
> 
> If you pass 0 or NULL in a function call where there is no prototype
> in scope you can loose equally bad.  On some platforms pointers to
> different types may have different sizes so if you don't know the type
> of the pointer you're casting to then you'll fail.

Ah, yes, of course, but that's why I made my initial complaint.  If '0'
were treated like every other integer constant then at least then those
people most likely to make such mistakes (i.e. C programmers who have
never used real C, or forgotten that they ever did, and have just used
ANSI's Standard C and it's mighty derrivatives! ;-) will be warned that
they are writing code that might not be as portable as it could be.

Furthermore even with Standard C there's still the possibility of
compiling code with traditional function definitions (and declarations
without prototypes), and as far as I can remember it's not "legal" for a
Standard C compiler to complain about missing prototypes in such a
situation (and indeed GCC 2.7.2 doesn't -- it only warns about function
declarations and definitions that are not prototypes [and it gets the
wording wrong in the latter case]).  If you try to pass '0' instead of
'(void *)0' to such a function then your code may fail with both
Standard C and traditional C compilers and only lint will save your
butt.

So far as I can see c9x isn't going to fix this problem either -- their
answer is to try, yet again, to declare the millions of lines of working
C code with traditional function declarations and definitions as
obsolescent (in hopes that maybe when the name of the standard becomes
Y2K compliant that they'll be able to eliminate such "features"
entirely).  I believe the real fix would have been to revert to the
traditional interpretation of function parameters, but still strongly
suggest function prototypes (using them to supply implicit cast
operators), and of course to revert traditional style function
definitions to fully supported status.  New C code would continue to
work, and old C code wouldn't need rewriting, though it could benefit
from the addition of prototypes (which can be mechanically generated
much easier than rewriting definitions, esp. those with varargs!).

There are of course many other "problems" (or perhaps "compromises")
with Standard C, but none so disparaging as this one!  It is at the root
of many issues.

> So function calls without a prototype should be banned. :-)  And then 0
> is as good as NULL.

Yeah, just so long as you don't require me to rewrite my function
definitions!  However I still think prototypes suck.  They're the wrong
answer to the wrong problem.  That's a job for lint, not the compiler.
If you want that kind of parameter checking and type coersion then you
should use Pascal or Modula-N or anything else Wirth contributed to!  ;-)

CPUs are fast and memory is cheap now -- why don't we just declare that
all function parameters are widened to be the same rank as the widest
base type (eg. (long long) or something) instead?  ;-)

"C-2000!  THE ultimate Y2K fix -- it kills your old code DEAD!  Start
fresh for the New Millenium!"  I get first dibbs on C-2000.COM!!!! :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>