Re: standards/52819: a64l should sign-extend its result when long has more than 32 bit

[Daniel Schemmel <daniel.schemmel%comsys.rwth-aachen.de@localhost>]

The following reply was made to PR standards/52819; it has been noted by GNATS.

From: Daniel Schemmel <daniel.schemmel%comsys.rwth-aachen.de@localhost>
To: <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: standards/52819: a64l should sign-extend its result when long has
 more than 32 bit
Date: Fri, 15 Dec 2017 01:39:05 +0100

 On 14.12.2017 19:35, Robert Elz wrote:
 > The following reply was made to PR standards/52819; it has been noted b=
 y GNATS.
 >
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: standards/52819: a64l should sign-extend its result when l=
 ong has more than 32 bit
 > Date: Fri, 15 Dec 2017 01:33:35 +0700
 >
 >      Date:        Thu, 14 Dec 2017 15:10:00 +0000 (UTC)
 >      From:        daniel.schemmel%comsys.rwth-aachen.de@localhost
 >      Message-ID:  <20171214151000.B57907A180%mollari.NetBSD.org@localhost>
 > =20
 > =20
 >    |  When undoing the conversion, the lower 32 bit of the result are
 >    | 0xFFFFFFFF which, when sign-extended should yield -1.
 > =20
 >  I am not sure I agree with that interpretation.   There is no way to r=
 epresent
 >  a sign bit in the encoded form - it is not needed, as only positive (i=
 ncl 0)
 >  values have a defined representation.
 I agree that the encoded form ("zzzzz1" for this example) need not deal
 with a sign bit. The sign-extension is applied to the "resulting value"
 of a64l only.
 > Hence when re-encoded, there is no
 >  sign bit (assuming that the upper bit of a 32 bit value is a sign bit =
 is
 >  incorrect, nothing in the spec says that).
 While generally the C standard is indeed very open about the
 bit-representation of a negative number, the ABI for the target
 architecture(s) clearly defines what a signed 32 bit number means.
 > Since only positive values are
 >  ever ended, the (missing, or elided) sign bit is always a 0.  That 0 i=
 s
 >  extended to the upper bits when long has more than 32 bits - that woul=
 d be
 >  the "sign extension" expected.
 That is a rather elegant way to give the sign-extension meaning in the
 absence of an actual sign. However, in my understanding, sign-extension
 is a concept that only applies to signed numbers (i.e. the C-standard
 defines a sign bit for signed integers, but not for unsigned integers),
 especially as the POSIX standard oftentimes uses the wording "set to
 zero", but only very rarely talks about sign-extension. Another wording
 that is used at least once is "high-order bits beyond the specified
 character size are cleared" (IEEE 1003.1-2008 A11.2.2).
 
 In fact, all mentions of sign-extension I could find in POSIX 2008 read
 along these lines: "sign-extension of a variable of type char on
 widening to integer is implementation-defined" (see e.g. getc or
 getchar). Keeping your interpretation in mind, this can either be
 interpreted that it is implementation-defined whether sign-extension is
 done, or whether a sign-extension of a one or a zero takes place.
 >  This then makes it possible to achieve what the application usage says=
 
 >  can be done ...
 > =20
 >     If the type long contains more than 32 bits, the result of
 >     a64l(l64a(x)) is x in the low-order 32 bits.
 > =20
 >  That's not normative text, but it is a strong hint as to the expected
 >  behaviour, if x is 0xFFFFFFFF then the result needs to be 0XFFFFFFF in=
 
 >  the low 32 bits - the same value as was passed in.=20
 The value 0xFFFFFFFFFFFFFFFF =3D -1L also contains the result 0xFFFFFFFF
 in the low 32 bits, so neither interpretation violates this comment.
 >  I will ask the austin group for a ruling on this though.
 > =20
 >  kre
 An official ruling on this would be interesting to hear, as I found
 additional implementations going in either direction (glibc returns
 0xFFFFFFFF, while musl returns 0xFFFFFFFFFFFFFFFF).
 
 Thank you very much for your time,
 Daniel