Re: makecontext and its arguments

[Andreas Schwab <schwab at suse dot de>]

Ulrich Drepper <drepper@redhat.com> writes:

|> Andreas Schwab wrote:
|> 
|> > This is the crux of the problem.  makecontext talks about "integer
|> > arguments", and __int128 is an integer type.  So it is obliged to handle
|> > this.
|> 
|> This is a completely bogus argument.  Every platform could define
|> int1024_t or whatever.

Yes, that's all I said.

|> These don't count.

Why?  An extended integer type is also an integer type (6.2.5[#4]).

|> At the time the interface was introduced only char, short, int, and
|> long were available.

Irrelevant.  The specification is part of the current POSIX standard, and
the current POSIX standard does define extended integer types (by
reference to the C standard).

|> Nothing else can be expected to work.  The method described earlier
|> works perfectly for this and the proposed attribute has the potential
|> to help many more applications which would suffer from this broken
|> calling convention.

There is no broken calling convention.  You just cannot use va_arg(,long)
to retrieve an argument of type int (7.15.1.1[#2]).

|> > This is not what the specification says.
|> 
|> It says so implicitly.

Chapter and verse, please.

|> Whatever is not explicitly specified is implicitly left undefined.  And
|> undefined means garbage is allowed.  And this is what happens on most
|> platforms.

I agree that the specification of makecontext is defective, but the
closest approximation is to do s/integer/int/, and that makes our
implementation nonconforming.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."