Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: prototypes required ? Keywords: printf stdargs prototypes Message-ID: <14213@smoke.BRL.MIL> Date: 22 Oct 90 18:52:08 GMT References: <2150@lupine.NCD.COM> <14195@smoke.BRL.MIL> <2174@lupine.NCD.COM> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 43 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 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 cannot include )? >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 into >some other file (e.g. ) and then having both and > include ? No, that wouldn't get around the problem of having #include 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.