A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1108 ====================================================================== Reported By: nsz Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1108 Category: Base Definitions and Headers Type: Error Severity: Editorial Priority: normal Status: Resolved Name: Szabolcs Nagy Organization: musl libc User Reference: Section: limits.h Page Number: Line Number: Interp Status: --- Final Accepted Text: http://austingroupbugs.net/view.php?id=1108#c4041 Resolution: Reopened Fixed in Version: ====================================================================== Date Submitted: 2016-12-09 17:00 UTC Last Modified: 2018-08-24 12:54 UTC ====================================================================== Summary: LONG_MIN must be <= -2147483648 ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0001197 Omission from 1108: LONG_MIN must be &l... ======================================================================
---------------------------------------------------------------------- (0004090) kre (reporter) - 2018-08-24 12:54 http://austingroupbugs.net/view.php?id=1108#c4090 ---------------------------------------------------------------------- Re note 4089 If the standard changes as mentioned, the pre-call check can still be done if desired (which makes the code C standard conformant) but if POSIX compliance is all that is needed, then a post-call check can be xmag = abs(x); if (xmag < 0) { /* special handling */ } which turns out to work (on a 2's complement system, ie: anything POSIX conformant) when abs is a function, or when it is a macro... #define abs(x) ((x) < 0 ? -(x) : (x)) (and yes, I know that would evaluate its operand twice - the advantage of the macro is that it is data type agnostic, it works for int, long, ssize_t, intmax_t, float, double, long double ...) I don't usually comment on issues like this one, but FWIW, I support the change - it is perfectly reasonable for any particular implementation to define what happens for its implementation when a standard says that something is undefined. That means it is perfectly reasonable for all implementations, which are POSIX conformant, to define arithmetic as being what 2's complement produces (without traps for integers, other than divide by 0) and then if all implementations implement it that way, it is perfectly reasonable for the POSIX standard to say that is what happens, so users can rely on it in a more portable way than "just my implementation". This makes zero difference to anyone writing C standards conformant code, as if there is any chance that xxx_MIN will be involved in any arithmetic which could cause undefined C behaviour, the code needs to check before doing the operation. Hence such code will never do abs(INT_MIN) and what POSIX says will happen in such a case is irrelevant. That compiler writers prefer as much to be undefined as possible, so they can do whatever they like, instead of what is reasonable, doesn't bother me at all. Let them deal with it. Issue History Date Modified Username Field Change ====================================================================== 2016-12-09 17:00 nsz New Issue 2016-12-09 17:00 nsz Name => Szabolcs Nagy 2016-12-09 17:00 nsz Organization => musl libc 2016-12-09 17:00 nsz Section => limits.h 2016-12-09 18:40 EdSchouten Note Added: 0003512 2016-12-09 22:25 nsz Note Added: 0003513 2018-06-07 16:10 geoffclare Note Added: 0004041 2018-06-07 16:11 geoffclare Interp Status => --- 2018-06-07 16:11 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1108#c4041 2018-06-07 16:11 geoffclare Status New => Resolved 2018-06-07 16:11 geoffclare Resolution Open => Accepted As Marked 2018-06-07 16:11 geoffclare Tag Attached: issue8 2018-07-11 21:10 cmsmith Note Added: 0004050 2018-07-12 08:13 geoffclare Note Added: 0004051 2018-07-12 11:43 shware_systems Note Added: 0004052 2018-07-30 19:02 eblake Note Added: 0004064 2018-07-30 20:29 eblake Relationship added parent of 0001197 2018-08-23 16:32 eblake Resolution Accepted As Marked => Reopened 2018-08-24 08:29 geoffclare Note Added: 0004089 2018-08-24 08:30 geoffclare Note Edited: 0004089 2018-08-24 12:54 kre Note Added: 0004090 ======================================================================
