prototypes required ?
Ron Guilmette
rfg at NCD.COM
Mon Oct 22 04:45:48 AEST 1990
In article <14195 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>Section 4.1.2.1 says: "Each header declares or defines all identifiers
>listed in its associated section, ..." While it does not explicitly
>require that prototypes be used, a strictly conforming program must
>assume that the standard headers might use prototypes. Otherwise, it
>would be depending on undefined behavior.
Allow me to stray a bit from my original question (which has been adequately
answer by a number of posters -- thank you all).
If I understand you correctly Doug, you are saying that printf() could
be declared in <stdio.h> in an unprototyped form (in a standard conforming
implementation).
This gives me pause.
It seems that GCC (which is occasionally known to be standard conforming :-)
will complain about:
extern int foo ();
extern int foo (int, ...);
It says:
problem.c:2: conflicting types for `foo'
problem.c:2: A parameter list with an ellipsis can't match
problem.c:2: an empty parameter name list declaration.
problem.c:1: previous declaration of `foo'
Therefore, I imagine that it would also complain about:
extern int printf ();
extern int printf (const char *, ...);
Now if the first declaration was in <stdio.h> and if the second was in my
(standard conforming?) program, I believe that GCC would also still complain
(correctly, I believe).
So if the declarations in `system' include files are allowed to be either
prototyped or unprototyped, does this imply that my standard conforming
programs must *not* contain (potentially conflicting) declarations for
things which the standard requires be declared in any of the `system'
include files which my program happens to include?
><stdio.h> must not rely on the inclusion of <stdarg.h> nor include
><stdarg.h> itself...
I understand the `non-reliance' rule (and it even makes sense), but what
about this second rule (i.e. that <stdio.h> cannot include <stdarg.h>)?
I believe that such a rule exists, but just out of curiosity, which section
of the standard is that rule given in?
Also, what could be the reason for such a rule? Isn't it a bit
superfluous? Could it not be trivially circumvented by placing all of the
stuff that would normally go into <stdarg.h> into some other file (e.g.
<foobar.h>) and then having both <stdio.h> and <stdarg.h> include <foobar.h>?
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg at ncd.com uucp: ...uunet!lupine!rfg
// Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
More information about the Comp.std.c
mailing list