NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: Sat, 16 Dec 2017 06:17:14 +0700

     Date:        Fri, 15 Dec 2017 02:20:01 +0000 (UTC)
     From:        Daniel Schemmel <daniel.schemmel%comsys.rwth-aachen.de@localhost>
     Message-ID:  <20171215022001.995857A1F7%mollari.NetBSD.org@localhost>
 
   |  The value 0xFFFFFFFFFFFFFFFF =3D -1L also contains the result 0xFFFFFFFF
   |  in the low 32 bits, so neither interpretation violates this comment.
 
 That would be more relevant if that's what the (non-normative) text said, but
 it doesn't say the result contains x in the low 32 bits, it says the result
 *is* x in the low 32 bits.   But this is no more than a hint at best.
 
   |  An official ruling on this would be interesting to hear,
 
 Still nothing from a source I would consider authoritative - there may
 never be this way (I suspect that the original authors no longer participate,
 so everyone now is just guessing...)   In that case there would need to be
 an actual determination via a defect report which can result in changed text.
 
 However, we did discover that Solaris apparently implements it the way
 you believe is correct.
 
 And there was a suggestion that the functions be marked as obsolete and
 simply deleted, as being mostly useless and not well defined - if that were
 to happen they'd be marked as obsolete in the next major revision of the
 standard, and then deleted from the one after that (which will be years away).
 
 I'd think this would be quite likely if your interpretation is the one
 that is considered the correct one - as a part of functions that encode
 an (in range) value, and then decode it again producing a different value,
 are not exactly useful for much.
 
 kre
 


Home | Main Index | Thread Index | Old Index