Date: Tue, 20 Jan 1998 20:56:49 -0600 (CST) From: Joel Ray Holveck <joelh@gnu.org> To: fenner@parc.xerox.com Cc: fenner@parc.xerox.com, current@freebsd.org, sef@kithrup.com Subject: Re: Nasty GCC bug? Message-ID: <199801210256.UAA00312@detlev.UUCP> In-Reply-To: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> (message from Bill Fenner on Tue, 20 Jan 1998 18:23:34 PST) References: <98Jan20.182345pst.177476@crevenia.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801210256.UAA00312>