From owner-freebsd-current Tue Jan 20 19:00:59 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04002 for current-outgoing; Tue, 20 Jan 1998 19:00:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03989 for ; Tue, 20 Jan 1998 19:00:42 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (newip54.wcc.net [206.104.247.54]) by wcc.wcc.net (8.8.7/8.8.7) with ESMTP id UAA27919; Tue, 20 Jan 1998 20:57:21 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id UAA00312; Tue, 20 Jan 1998 20:56:49 -0600 (CST) (envelope-from joelh) Date: Tue, 20 Jan 1998 20:56:49 -0600 (CST) Message-Id: <199801210256.UAA00312@detlev.UUCP> To: fenner@parc.xerox.com CC: fenner@parc.xerox.com, current@freebsd.org, sef@kithrup.com In-reply-to: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> (message from Bill Fenner on Tue, 20 Jan 1998 18:23:34 PST) Subject: Re: Nasty GCC bug? From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It's easy to read it to say that promotions are required. However, > all it really says is that ANSI only guarantees that things work if > you match types with the promoted type. This is correct. After rereading the standard, it actually does say that the types have to match after promotion, not that it has to be passed that way. I personally wouldn't want to build a compiler and library that does it differently, though. > However, if you have some way to > intuit what type was passed in (e.g. Terry's description of an argument > passing scheme which passes types along with values and delays > promotion until required), you might see a loop like: > switch (va_type(ap)) { /* non-ANSI function */ > case VA_CHAR: > c = va_arg(ap, char); /* ANSI says this is undefined */ > break; > > ... > } > Now, that usage of va_arg(), according to ANSI, is undefined. That > just means that ANSI doesn't tell us what it's supposed to do, not that > ANSI requires that it doesn't do something useful. I see no way to do this without breaking both unprototyped code and NetBSD binary compatibility. (Actually, I see one other way if the only functions to use this will only be called by functions compiled knowing that this would be used, but it is not reentrant.) If we could do it sans breakage, it wouldn't be a bad thing. But I suspect that if you try to work out a proof, it would show that it must break something. > I was just trying to refute sef's assertion that a compiler/library > that implemented printf() in this way was buggy or wrong. It's not. > It's defining a certain behavior that ANSI chose not to define. Terry > is asserting that FreeBSD should have this behavior, which is a fine > thing to have an argument about, but it shouldn't be based upon an > assertion that it's an incorrect thing to do. I do agree with that. Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped