This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Further HPUX 11.00 include file woes
- To: Richard dot Begg at colesmyer dot com dot au, bkorb at veritas dot com
- Subject: Re: Further HPUX 11.00 include file woes
- From: Steve Ellcey <sje at cup dot hp dot com>
- Date: Tue, 17 Jul 2001 15:10:57 -0700 (PDT)
- Cc: gcc-patches at gcc dot gnu dot org
> Let's see if I now understand this... the __va__list definition is there to
> allow std namespace support, and effectively varies the va_list definition.
> My question is, why is vsnprintf() the only function to receive this
> treatment? Shouldn't all of the variable argument functions be handled the
> same way?
You are right, I did some investigation in the HP bug database and found
that the use of __va__list in vsnprintf is a mistake and it should be
__va_list. I saw all the definitions of __va__list but I didn't realize
that varargs.h is the only place it should get used.
> I'm a little reluctant to go changing a whole bunch of duplicate definitions
> in multiple include files, particularly when most of them appear to be
> unused. The only actual use of __va__list appears to be in stdio.h (the
> offending vsnprintf() declaration) and varargs.h. Given that GCC completely
> replaces varargs.h anyway, perhaps all we need to do is fix the __va__list
> definition in stdio.h? Does the std::va_list definition need to be fixed as
> well?
I think you are right, given that __va__list should only be used on
varargs.h and GCC replaces this completely it doesn't make sense to
change all the definitions. I now think the original fix is the way to
go (change __va__list to __va_list in the vsnprintf prototype and later
have it changed to __gnuc_va_list).
Steve Ellcey
sje@cup.hp.com