From owner-freebsd-current Tue Jan 20 17:14:29 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25441 for current-outgoing; Tue, 20 Jan 1998 17:14:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA25419 for ; Tue, 20 Jan 1998 17:14:15 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52179(1)>; Tue, 20 Jan 1998 17:14:13 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Tue, 20 Jan 1998 17:14:09 -0800 To: Sean Eric Fagan cc: current@freebsd.org Subject: Re: Nasty GCC bug? In-reply-to: Your message of "Tue, 20 Jan 98 14:06:21 PST." <199801202206.OAA18817@kithrup.com> Date: Tue, 20 Jan 1998 17:14:03 PST From: Bill Fenner Message-Id: <98Jan20.171409pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan wrote: >Terry said: >>... on systems which do not use an >>integer stack based calling convention, the value can be treated as >>its type by the varradic function, instead of being treated as an int. >>It is the promotion caused by the calling convention that is the >>source of the breakage. > >It *has* always been the case; not doing it this way is a bug. Not quite. If you don't do it this way, the behavior is undefined -- section 7.8.2.1: ...or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined. So it's not *wrong* to allow chars to be passed into varargs functions as chars, but the ANSI C specification doesn't require it. Terry wants to define some of this undefined behavior. Bill