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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@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: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>
 
 
   |  When undoing the conversion, the lower 32 bit of the result are
   | 0xFFFFFFFF which, when sign-extended should yield -1.
 
 I am not sure I agree with that interpretation.   There is no way to represent
 a sign bit in the encoded form - it is not needed, as only positive (incl 0)
 values have a defined representation.   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).  Since only positive values are
 ever ended, the (missing, or elided) sign bit is always a 0.  That 0 is
 extended to the upper bits when long has more than 32 bits - that would be
 the "sign extension" expected.
 
 This then makes it possible to achieve what the application usage says
 can be done ...
 
    If the type long contains more than 32 bits, the result of
    a64l(l64a(x)) is x in the low-order 32 bits.
 
 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.
 
 I will ask the austin group for a ruling on this though.
 
 kre