🚀 go-pugleaf

In article <2174@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>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).

In some implementations it might work, not necessarily in all.

>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?

A strictly conforming program must not misdeclare any of the standard
library functions (consequence of 4.1.2.1).  Also (see 4.1.6), special
care must be taken if you both include the standard header and declare
one of its functions yourself.

>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?

4.1.2, 4.1.2.1.  Note also that #include <...> syntax does not imply that
any of the standard headers actually exist as files that look like pieces
of C source code; thinking of the standard headers as included files is
misleading.

>Also, what could be the reason for such a rule?

So that the programmer knows precisely what the effect of including a
standard header will be.

>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>?

No, that wouldn't get around the problem of having #include <stdio.h>
defining one or more va_* identifiers as a side effect, which is not
allowed.

A way to do this right has been described previously in this newsgroup.