This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Believe found bug, would like to be sure w/experts POV


On Mon, 2004-09-13 at 21:16, George Garvey wrote:
> # 43 "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/stdarg.h" 3 4
> typedef __builtin_va_list __gnuc_va_list;

GCC uses the same stdarg.h for all targets, or at least most all
targets.  __builtin_va_list is an internal builtin type that is target
dependent.  For x86, it is "char *".  Thus anything char * matches the
va_list overloaded function.  There isn't really any __builtin_va_list
type here.  There is only char *.

Some targets use a structure for __builtin_va_list.  A structure pointer
presumably won't match "char *".  This is what I meant when I said that
targets with unique types for builtin_va_list would work, but others
won't.  Since this structure will be different from any structure in the
user program, there should be no possibility of getting an accidental
match with va_list.

>    This looks like a typedef to me, even though __builtin_va_list is
> opaque. That isn't actually the reason why it isn't working. I'm sorry to
> beat a dead horse, but I'd really like to understand this.

I'm not a C++ expert, but I don't think the existence of a typedef
matters here.  If something is typedef'ed to char *, then it is char *
when choosing which overloaded function to call.

>    I changed the code sent with the original question to use nva_list
> instead of va_list. nva_list is "typedef void *nva_list." I have exactly
> the same results.

Again, I am not a C++ expert, but presumably void * matches char *.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]