Quoting Oleg Goldshmidt <[EMAIL PROTECTED]>: > > Shachar, > > Shachar Shemesh <[EMAIL PROTECTED]> writes: > > > Let's get one thing clear. NOTHING results in undefined behavior. If > > anything resulted in undefined behavior, it would have been impossible > > to pass it between caller and callee. > > I don't understand this statement. I suspect that you have a different > mental picture of "undefined behavior". The official "definition of > undefined behavior" is that *anything* may happen. >
I'm barging in at the middle a bit so I don't know the context, but undefined behaviour means that the specs don't define what should happen in such a case and thus the result is compiler dependent. For example IIRC the specs don't define what free((void *)0) should do, so it can either return cleanly doing nothing or cause a segmentation fault depending on the compiler. > I killed a list of things that you think are happening when you pass > different types to a function. It looks to me that it originates from > your mental picture of how you would design the implementation. I am > not a competent enough compiler writer to agree or disagree, but maybe > that's not the only implementation possible, and maybe different > options are taken into account. > > > What you do have is a loss of information about the type. You only > > get that for non explicitly defined type - i.e. - types passed as > > part of the ellipsis. For that reason you perform automatic > > promotion, and for that reason you cannot use certain types FOR > > ACTUAL "..." PARAMETERS. > > Check the man page for va_start on your favorite Linux box - you'll > see there are restrictions on the type of the "last" (before ...) > parameter. Unfortunately, it does not mention references, since it is > likely C-oriented. It does say that functions and arrays are not > allowed. > > > In order to further prove that this is a compiler bug: > > 1. It warns that the actual program will abort. Actual program runs > > fine, and does exactly what you would expect it to do. > > > > 2. Neither g++-3.4 nor Visual Studio see any problem with this > > construct. g++-3.3 and g++-2.95 complain, and 3.3 even gives doomsday > > warnings that this will crash and burn, but in reality everything > > works great. > The reason the specs require a parameter of a specific type is that the extra arguments go on the stack. You need to know the size of the last parameter before the ... as the ansi defenition for va_start is void va_start( va_list arg_ptr, prev_param ); you look at the pointer for prev_param and then add its size to get a pointer to the start of the arguments. The unix version doesn't use the last parameter (probably because certain implementations pass the first few parameters in registers instead of the stack) and thus va_start is defined as void va_start( va_list arg_ptr ); With this implementation I don't see a problem with the last parameter as long as you know where the first parameter in ... goes on the stack. > I don't have a copy of the Standard at hand, that is why I resorted to > Google. If I am right in my recollection and the Standard does indeed > say that failure to satisfy the restrictions on the type of the "last" > argument results in undefined behaviour, then all of the above > (dealing with it just fine, issuing doomsday warnings, failing at > runtime, etc) is perfectly correct behaviour, and cannot be considered > a compiler bug. > > I am afraid you are trying to surmise what the "logical" behaviour > should be, and blame gcc for not behaving as you expect. > > I have a suggestion. If you post your question to > comp.lang.c++.moderated or to an appropriate gcc forum someone there > will explain what happens, and probably quote the Standard to > you. I'll be happy to learn what the authoritative answer is. > > -- > Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ================================================================To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
