On Mon, Jun 02, 2014 at 12:00:41PM +0200, Florian Weimer wrote: > On 05/31/2014 08:56 AM, Alan Modra wrote: > > >>It's fine to change ABI when compiling an old-style function > >>definition for which a prototype exists (relative to the > >>non-prototype case). It happens on i386, too. > > > >That might be so, but when compiling the function body you must assume > >the worst case, whatever that might be, at the call site. For K&R > >code, our error was to assume the call was unprototyped (which > >paradoxically is the best case) when compiling the function body. > > Is this really a supported use case?
Of course! We still have K&R code lying around, as evidenced by the PR. > I think I remember tracking > down a bug which was related to a lack of float -> double promotion > because the call was prototyped, and the old-style function > definition wasn't. This would have been on, ugh, SPARC. I think > this happened only in certain cases (float arguments, probably). Yes, there are some limitations on parameter types that may be used with unprototyped functions. > Does this trigger more often on ppc64 ELFv2, to the extend it > becomes a quality-of-implementation issue? I'm pretty sure the > standards do not require a particular behavior in such cases. The PR isn't about the sort of parameter mismatch that you seem to be thinking about. The code in question is perfectly legal old-style K&R where there is no float/double or int/long/void * trouble. -- Alan Modra Australia Development Lab, IBM
