On 08/08/2018 05:24 PM, Niall Douglas wrote:
https://docs.google.com/viewer?a=v=forums=MTEwODAzNzI2MjM1OTc0MjE3MjkBMDIyMjg0NDY2NTc4NzYyMDQzODYBX1RlYjRCNjREQUFKATAuMQFpc29jcHAub3JnAXYy=0
Comments are welcome, particularly on how best to offer POSIX functions
in a form both binary compatible with old code, and which calls the
_Fails(errno) form in newly compiled code.
An initial comment in regards to the example on page 5:
1 int abs(int x)
2 {
3 if(x == INT_MIN)
4 {
5 errno = ERANGE;
6 return 0;
7 }
8 return (x < 0) ? -x : x;
9 }
We've just had a discussion on whether standard-compliant abs() (which
is currently undefined on INT_MIN) should be permitted and/or required
to have well-defined behavior (either in the one direction of returning
INT_MIN, as that is the fewest assembly instructions on typical
hardware, or in the direction of adding errno handling, as you have done
here). The verdict is not final (I wish I could point you to mailing
list archives, but https://www.opengroup.org/austin/mailarchives/ points
to gmane, which is no longer functional, and I don't know of any other
web archival visiting the Austin list). But so far, a rough consensus
from the discussion on bug http://austingroupbugs.net/view.php?id=1108
and http://austingroupbugs.net/view.php?id=1197 is that integral
functions, like abs(), should NOT signal a range error for performance
reason (or that setting errno to ERANGE should be a feature of
floating-point math, not integer math), and that the wording in 1108
will be once again relaxed to leave behavior of abs(INT_MIN) undefined,
rather than well-defined (any specific implementation can, of course,
define behavior as an extension to POSIX).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
