Message-Id: <200006060133.VAA10679@qnx.com>
Subject: Re: ANSI C and stdio.h
To: djgpp-workers AT delorie DOT com
Date: Mon, 5 Jun 2000 21:33:36 -0400 (EDT)
From: "Alain Magloire" <alain AT qnx DOT com>
In-Reply-To: <393BF350.4CF96661@softhome.net> from "Laurynas Biveinis" at Jun 05, 2000 09:37:04 PM
X-Mailer: ELM [version 2.5 PL0b1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 
> Alain Magloire wrote:
> > Maybe it's me who got this backward or I've missed a couple of threads.
> > To recap what I've understood in this thread, ANSI C says that
> > <stdarg.h> should not be part of <stdio.h> because it polluates
> > the namespace etc ... (I do not have the rationale).  Most OS/platforms
> > go around this, for functions like vfprintf(..) by including their
> > own header .i.e solaris <sys/va_list.h> or define va_list Watcomm etc ..
> 
> Not va_list but __va_list, __gnu_c_va_list, __builtin_va_list whatever.
> 

Sorry about this and the extra traffic, but I thing the confusion
came after this message :

----------------------
 From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> 
 To: Laurynas Biveinis <lauras AT softhome DOT net> 
 CC: djgpp-workers AT delorie DOT com 
 Subject: Re: ANSI C and stdio.h 

  > Date: Sun, 04 Jun 2000 17:56:44 +0300
  > From: Laurynas Biveinis <lauras AT softhome DOT net>
  > 
  > Eli Zaretskii wrote:
  > > > Note that stdarg.h should be included as well. Why?
  > > 
  > > Because that's where va_list is supposed to be defined.
  > 
  > So including <stdio.h> in theory is not sufficient?

  I don't have the ANSI standard handy, but IIRC, if you want to *use*
  the functions that depend on va_list, then you need stdarg.h.  Like DJ
  explained, our stdio.h includes stdarg.h to minimize FAQs.
----------------------

My impression was <stdio.h> included <stdarg.h> despite ANSI C says it
should not and it was done to make life of the users easier.

> > Some other just includes <stdarg.h>  DJGPP, GNU/Linux/Glibc (?)
> 
> Wait, now I don't understand you. DJGPP's <stdio.h> does not include
> <stdarg.h>, neither glibc does.

I was not sure hence my (?), at least in on the GNU/Linux here
/usr/include/stdio.h:
  __BEGIN_DECLS

  #ifndef __need_FILE
  # define _STDIO_H       1
...
  # include <stdarg.h>  
...
  #endif /* Don't need FILE.  */
  #undef  __need_FILE      

This is GNU Lib C 2.1.1

It seems to be protected by a macro __need_FILE, but glibc headers are
notoriously complex, maybe there is more then meet the eyes.


> 
> > And on those platforms if people takes things for granted
> > code like this :
> > 
> > #include <stdio.h>
> > void warnings (char *s, ...)
> > {
> >     char *t;
> >     va_list ap;
> > 
> >     va_start(ap, s);
> >     while (t = va_arg(ap, char *))
> >     {
> >         /* do stuff */
> >     }
> >     va_end(ap);
> > }
> > 
> > Will work compile under DJGPP, GNU/Linux, since <stdio.h> include <stdarg.h>
> 
> This piece of will compile but won't link because of missing va_start() & Co.

Yes that was my point, if <stdio.h> was pulling <stdarg.h> behind the curtains
users would get use of code like this working which is incorrect, <starg.h>
must be included.  But forget it now, seems to be a misunderstanding on
my part.

> That's why I've said that updating headers won't cause any problems. But Eli
> told that it's wrong - va_start() could be called in other source file.

I would not dare comment on this, it will probably result in another
"quiproquo" ;-)

bye.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!