Path: utzoo!attcan!uunet!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c
Subject: Re: prototypes required ?
Keywords: printf stdargs prototypes
Message-ID: <2174@lupine.NCD.COM>
Date: 21 Oct 90 18:45:48 GMT
References: <14164@smoke.BRL.MIL> <2150@lupine.NCD.COM> <14195@smoke.BRL.MIL>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 62

In article <14195@smoke.BRL.MIL> gwyn@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@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.