Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-23 20:24:11 +0700, Robert Elz wrote:
> Date:Mon, 23 Jul 2018 15:13:21 +0200
> From:Vincent Lefevre 
> Message-ID:  <20180723131321.gb12...@zira.vinc17.org>
> 
>   | No, this is not impossible. The result of the test is 0.
> 
> Yes, I know, what I meant was that it is impossible for an
> unsigned value to ever be < 0 - which is what that test is
> based upon.

No, this is just a test. The expression is a valid C expression
with a well-defined result, which may be 0 or 1.

> But because of that, if one writes code like
> 
>   unsigned x,y,z;
> 
>   z = x - y;
>   if (z < 0) { /* whatever */ }
> 
> the code is broken,

This is valid C code. The "if (z < 0) { /* whatever */ }" is just
dead code here. But this is not incorrect. Whether this is what
the user intended to write is another matter.

> and because of that, compilers warn about it

GCC will warn just with -Wtype-limits, which isn't even in -Wall,
thus not in general because such always-true or always-false tests
are common with portability code:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963

But even if one gets a warning, this doesn't make the code wrong.
Warnings are there just to signal a potential issue, sometimes
with many false positives, like with this kind of tests.

And my code was different: (T) -1 < 0

Here, (T) -1 is a constant expression. Thus GCC shouldn't warn on it,
even with -Wtype-limits, as documented:

  -Wtype-limits
 Warn if a comparison is always true or always false due to the
 limited range of the data type, but do not warn for constant
 
 expressions.  For example, warn if an unsigned variable is compared
 ^^^
 against zero with "<" or ">=".  This warning is also enabled by
 -Wextra.

I get a warning, but this is a bug in the compiler. The goal concerning
constant expressions is to avoid even more false positives.

> (just like, in this meaningless example, they would also warn about
> x and y being used without being set...)

This other warning is useful because this is undefined behavior.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-23 20:04:21 +0700, Robert Elz wrote:
> Date:Mon, 23 Jul 2018 14:48:36 +0200
> From:Vincent Lefevre 
> Message-ID:  <20180723124836.ga12...@zira.vinc17.org>
> 
>   | For the signness, one can just do: (T) -1 < 0
> 
> Until the brain dead compilers started bitching about comparing
> an unsigned number for < 0 (which is impossible, of course, that's
> the point)

No, this is not impossible. The result of the test is 0.

> and by so doing breaking things - at least in envoronments which
> insist on switching on all warnings, and also treating all warnings
> as compile errors.

If compilers don't handle the above test, they are really broken.
(T) -1 < 0 is well defined in C, whether T is signed or unsigned.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: About issue 0001108 and abs(INT_MIN)

[Robert Elz]

Date:Mon, 23 Jul 2018 14:48:36 +0200
From:Vincent Lefevre 
Message-ID:  <20180723124836.ga12...@zira.vinc17.org>

  | For the signness, one can just do: (T) -1 < 0

Until the brain dead compilers started bitching about comparing
an unsigned number for < 0 (which is impossible, of course, that's
the point) and by so doing breaking things - at least in envoronments
which insist on switching on all warnings, and also treating all warnings
as compile errors.

kre

Re: About issue 0001108 and abs(INT_MIN)

[Joerg Schilling]

Vincent Lefevre  wrote:

> On 2018-07-23 08:06:46 +, Schwarz, Konrad wrote:
> > I don't think such code (to detect whether an arbitrary type is
> > signed or unsigned) exists.
>
> For the signness, one can just do: (T) -1 < 0
>
> Then, to get the minimum value of a signed type, assuming
> two's complement and no padding bits:
>
>   (2 * -((T) 1 << (sizeof(T) * CHAR_BIT - 2)))
>
> as said in the message I've posted a few days ago.

You can even check the hardware type.

On thursday, I changed my code to:

#define TYPE_ISSIGNED(t)(((t)-1) < ((t)0)) 
#define TYPE_ISUNSIGNED(t)  (!TYPE_ISSIGNED(t)) 
#if (-3 & 3) == 1   /* Two's complement */ 
#define TYPE_MSBVAL(t)  (2 * -(((t)1) << (sizeof (t)*CHAR_BIT - 2))) 
#else 
#define TYPE_MSBVAL(t)  ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) 
#endif 
#define TYPE_MINVAL(t)  (TYPE_ISSIGNED(t)   \ 
? TYPE_MSBVAL(t)\ 
: ((t)0)) 
#define TYPE_MAXVAL(t)  ((t)(~((t)0) - TYPE_MINVAL(t))) 


As a hint, you may use:

#if (-3 & 3) == 1
two's complement
#elif (-3 & 3) == 0
one's complement
#elif (-3 & 3) == 3
magnitude type
#endif

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-23 08:06:46 +, Schwarz, Konrad wrote:
> I don't think such code (to detect whether an arbitrary type is
> signed or unsigned) exists.

For the signness, one can just do: (T) -1 < 0

Then, to get the minimum value of a signed type, assuming
two's complement and no padding bits:

  (2 * -((T) 1 << (sizeof(T) * CHAR_BIT - 2)))

as said in the message I've posted a few days ago.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

RE: About issue 0001108 and abs(INT_MIN)

[Schwarz, Konrad]

> -Original Message-
> From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de]
> Sent: Thursday, July 19, 2018 4:53 PM
> To: vincent-o...@vinc17.net; austin-group-l@opengroup.org
> Subject: Re: About issue 0001108 and abs(INT_MIN)
> 
> Vincent Lefevre  wrote:
> 
> > The problem is not just the warning. If t is signed,
> >
> >   ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1)))
> >
> > will yield undefined behavior due to overflow. This means that
> > compilers may generate code that shows a behavior different from what

> A compiler that creates other than the expected behavior would need to create
> intentionally buggy code.
> 
> The question was to create working code that neither creates a warning with 
> newer
> nor with older compilers. Do you have such code?

I don't think such code (to detect whether an arbitrary type is signed or 
unsigned) exists.

As Vincent correctly wrote, signed arithmetic is allowed to trap;
my understanding is that this was so C could support IBM360-derived 
architectures
(non-trapping signed arithmetic is a recent addition to z-Series).

POSIX acknowledges the inability to programmatically discover the by stating, 
for each typedef
it specifies (e.g. in sys/types.h), whether the type is signed or unsigned.  
Where it does not, e.g., time_t
computation is significantly complicated, e.g., difftime() must be used in 
portable code.

((t) 1 << sizeof (t) * CHAR_BIT - 1) is an expression that evaluates to a 
t-sized word with the most
significant bit set.

Regards

Konrad

Re: About issue 0001108 and abs(INT_MIN)

[Hans Åberg]

> On 19 Jul 2018, at 14:13, Joseph Myers  wrote:
> 
> On Thu, 19 Jul 2018, Joerg Schilling wrote:
> 
>> Since the C++ people already think about making this to happen in ther next 
>> standard, it seems that the C compilers may do something similar in the 
>> future.
> 
> The latest version of the C++ proposal 
>  is 
> clear that it does not change undefined overflow (while adding the new 
> constraint to representations to reflect more or less universal existing 
> practice in that regard).  I quote:
> 
>Status-quo If a signed operation would naturally produce a value that 
>is not within the range of the result type, the behavior is undefined. 
>The author had hoped to make this well-defined as wrapping (the 
>operations produce the same value bits as for the corresponding 
>unsigned type), but WG21 had strong resistance against this.

Is this true for the int_t types, which require 2's complement? The 
uint_t types are required to compute modulo 2^N I recall, so it would seem 
that CPUs that support those also use those for the former but with a different 
interpretation in the set of integers.

Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-19 16:53:11 +0200, Joerg Schilling wrote:
> Vincent Lefevre  wrote:
> 
> > The problem is not just the warning. If t is signed,
> >
> >   ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1)))
> >
> > will yield undefined behavior due to overflow. This means that
> > compilers may generate code that shows a behavior different from
> > what you expect. Not just recent compilers. Compilers could already
> > do this 20 years ago without a warning. Perhaps some did. Perhaps
> > some users got crashes and other erratic behavior due to that, but
> > did not know the cause or did not notice.
> 
> A compiler that creates other than the expected behavior would need to create 
> intentionally buggy code.
> 
> The question was to create working code that neither creates a warning with 
> newer nor with older compilers. Do you have such code?

There was my answer on stackoverflow:

  
https://stackoverflow.com/questions/5617925/maximum-values-for-time-t-struct-timespec/39782264#39782264

To apply the same idea here:

#include 

#define CHAR_BIT 8
#define TYPE_MSBVAL1(t) ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1)))

#define TYPE_MSBVAL2(t) (2 * -((t) 1 << (sizeof(t) * CHAR_BIT - 2)))

int main (void)
{
  printf ("%d\n", TYPE_MSBVAL1(int));
  printf ("%d\n", TYPE_MSBVAL2(int));
  printf ("%ld\n", TYPE_MSBVAL1(long));
  printf ("%ld\n", TYPE_MSBVAL2(long));
  return 0;
}

Contrary to TYPE_MSBVAL1, TYPE_MSBVAL2 doesn't involve
undefined behavior (assuming two's complement).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: About issue 0001108 and abs(INT_MIN)

[Joerg Schilling]

Vincent Lefevre  wrote:

> The problem is not just the warning. If t is signed,
>
>   ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1)))
>
> will yield undefined behavior due to overflow. This means that
> compilers may generate code that shows a behavior different from
> what you expect. Not just recent compilers. Compilers could already
> do this 20 years ago without a warning. Perhaps some did. Perhaps
> some users got crashes and other erratic behavior due to that, but
> did not know the cause or did not notice.

A compiler that creates other than the expected behavior would need to create 
intentionally buggy code.

The question was to create working code that neither creates a warning with 
newer nor with older compilers. Do you have such code?



Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-19 16:10:35 +0200, Joerg Schilling wrote:
> /* 
>  * These macros may not work on all platforms but as we depend 
>  * on two's complement in many places, they do not reduce portability. 
>  * The macros below work with 2s complement and ones complement machines. 
>  * Verify with this table... 
>  * 
>  *  Bits1's c.  2's complement. 
>  *  100 -3  -4 
>  *  101 -2  -3 
>  *  110 -1  -2 
>  *  111 -0  -1 
>  *  000 +0   0 
>  *  001 +1  +1 
>  *  010 +2  +2 
>  *  011 +3  +3 
>  * 
>  * Computing -TYPE_MINVAL(type) will not work on 2's complement machines 
>  * if 'type' is int or more. Use: 
>  *  ((unsigned type)(-1 * (TYPE_MINVAL(type)+1))) + 1; 
>  * it works for both 1's complement and 2's complement machines. 
>  */ 
> #define TYPE_ISSIGNED(t)(((t)-1) < ((t)0)) 
> #define TYPE_ISUNSIGNED(t)  (!TYPE_ISSIGNED(t)) 
> #define TYPE_MSBVAL(t)  ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) 
> #define TYPE_MINVAL(t)  (TYPE_ISSIGNED(t)   \ 
> ? TYPE_MSBVAL(t)\ 
> : ((t)0)) 
> #define TYPE_MAXVAL(t)  ((t)(~((t)0) - TYPE_MINVAL(t))) 
> 
> It worked for 20 years without problems but recently some compilers
> decided to issue a warning.

The problem is not just the warning. If t is signed,

  ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1)))

will yield undefined behavior due to overflow. This means that
compilers may generate code that shows a behavior different from
what you expect. Not just recent compilers. Compilers could already
do this 20 years ago without a warning. Perhaps some did. Perhaps
some users got crashes and other erratic behavior due to that, but
did not know the cause or did not notice.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

On 2018-07-19 14:41:34 +0100, Davin McCall wrote:
> I agree completely but, and sorry if I'm missing something, the labs()
> function could still be required to return LONG_MIN if passed LONG_MIN,
> correct? It's just that the implementation changes from:
> 
>long labs(long i)
>{
>     return (i > 0) ? i : -i;
>}
> 
> 
> to, for example:
> 
>long labs(long i)
>{
>     if (i == LONG_MIN) return LONG_MIN;
>     return (i > 0) ? i : -i;
>}
> 
> 
> (which is potentially compiled to the same thing, though a brief test shows
> current compilers fail to do that).
> 
> So, this POSIX requirement doesn't actually impose any extra requirements on
> the C compiler, if I understand correctly - just on the implementation of
> the abs() functions.

The problem with the new POSIX requirement is not just the
implementation of the function, but

1. The programs will have less chance to be optimized. With ISO C's
   specification and without an knowledge on i, the compiler can
   assume that the result of labs(i) is in the range 0 .. LONG_MAX.
   But with the new POSIX requirement, the range of this result
   becomes LONG_MIN .. LONG_MAX.

2. For security-sensitive programs and for testing, UBsan would
   no longer be able to fail on labs(LONG_MIN).

3. The divergence between ISO C and POSIX could yield obscure failures
   when a program is not compiled in the mode it should be.

And labs(LONG_MIN) -> LONG_MIN would not bring something really useful
for the user. And this cannot even be regarded as a simplification if
the user wants to put the result in an unsigned type, because he would
still need to be very careful. For instance,

  unsigned long long a = labs(i);

will probably not give what the user expects on i = LONG_MIN.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: About issue 0001108 and abs(INT_MIN)

[Joerg Schilling]

Davin McCall  wrote:

> On 19/07/18 13:03, Joseph Myers wrote:
>
> On Thu, 19 Jul 2018, Joerg Schilling wrote:
>
>
>
> [...]
>
> Since POSIX de-facto only allowed two's complement machines since several 
> years
> already (the current change is just fixing the slipped parts in the standard),
> it is now well defined what happens in case of an integer overflow.
>
>
>
> No, it is very definitely undefined.  It's true that anyone programming in
> C on POSIX systems for about the past 20 years has probably in fact only
> needed to care about two's complement systems.  But it's also true that
> programming in C for about the past 20 years without a proper modern
> understanding of undefined behavior as discussed in the above blog posts
> (or otherwise avoiding anything the C standard says is undefined) is a
> rapid route to code that does not work correctly and introduces security
> holes.

If you believe this all makes sense, you are welcome to present new code for 
this piece of code:

#ifndef CHAR_BIT 
#ifdef  NBBY 
#define CHAR_BITNBBY 
#endif 
#endif 
 
/* 
 * Last resort: define CHAR_BIT by hand 
 */ 
#ifndef CHAR_BIT 
#define CHAR_BIT8 
#endif 
 
/* 
 * These macros may not work on all platforms but as we depend 
 * on two's complement in many places, they do not reduce portability. 
 * The macros below work with 2s complement and ones complement machines. 
 * Verify with this table... 
 * 
 *  Bits1's c.  2's complement. 
 *  100 -3  -4 
 *  101 -2  -3 
 *  110 -1  -2 
 *  111 -0  -1 
 *  000 +0   0 
 *  001 +1  +1 
 *  010 +2  +2 
 *  011 +3  +3 
 * 
 * Computing -TYPE_MINVAL(type) will not work on 2's complement machines 
 * if 'type' is int or more. Use: 
 *  ((unsigned type)(-1 * (TYPE_MINVAL(type)+1))) + 1; 
 * it works for both 1's complement and 2's complement machines. 
 */ 
#define TYPE_ISSIGNED(t)(((t)-1) < ((t)0)) 
#define TYPE_ISUNSIGNED(t)  (!TYPE_ISSIGNED(t)) 
#define TYPE_MSBVAL(t)  ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) 
#define TYPE_MINVAL(t)  (TYPE_ISSIGNED(t)   \ 
? TYPE_MSBVAL(t)\ 
: ((t)0)) 
#define TYPE_MAXVAL(t)  ((t)(~((t)0) - TYPE_MINVAL(t))) 


It worked for 20 years without problems but recently some compilers decided to 
issue a warning.

Note that the code you present 

-   needs to work on any platform used by UNIX

-   needs to work with any type from char up to the largest kardinal type 
supported by the actual compiler

-   needs to work with compilers that do not support "long long".

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: About issue 0001108 and abs(INT_MIN)

[Joseph Myers]

On Thu, 19 Jul 2018, Davin McCall wrote:

> So, this POSIX requirement doesn't actually impose any extra requirements on
> the C compiler, if I understand correctly - just on the implementation of the
> abs() functions.

In practice (and again for 20 years or more), compilers do not generate 
out-of-line calls to abs functions when optimizing - they expand those 
operations inline instead, so the implementation of the out-of-line abs 
function is essentially irrelevant (only ever used in unusual cases such 
as a function pointer the compiler can't tell points to abs).  And it's 
not even the inline expansion of a single abs call in isolation that's 
relevant - it's the optimization of a larger expression based on the known 
semantics of abs (such as returning a nonnegative value from any valid 
call).

(There are processors that use two's complement arithmetic, but provide an 
absolute value instruction that uses saturation on overflow rather than 
returning the negative argument value in that case.  For example, the TI 
C6X family of DSPs, which even has a Linux kernel port.  On such 
processors, an expansion of an isolated abs call without such optimization 
based on undefined behavior would naturally return INT_MAX not INT_MIN for 
an argument of INT_MIN.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: About issue 0001108 and abs(INT_MIN)

[Davin McCall]

On 19/07/18 14:41, Davin McCall wrote:


So, this POSIX requirement doesn't actually impose any extra 
requirements on the C compiler, if I understand correctly - just on 
the implementation of the abs() functions.




Ah, except I suppose that compilers have intrinsic knowledge of these 
standard C functions and assume that they always return >= 0 - never mind.

Re: About issue 0001108 and abs(INT_MIN)

[Davin McCall]

On 19/07/18 13:03, Joseph Myers wrote:


On Thu, 19 Jul 2018, Joerg Schilling wrote:

[...]

Since POSIX de-facto only allowed two's complement machines since several years
already (the current change is just fixing the slipped parts in the standard),
it is now well defined what happens in case of an integer overflow.

No, it is very definitely undefined.  It's true that anyone programming in
C on POSIX systems for about the past 20 years has probably in fact only
needed to care about two's complement systems.  But it's also true that
programming in C for about the past 20 years without a proper modern
understanding of undefined behavior as discussed in the above blog posts
(or otherwise avoiding anything the C standard says is undefined) is a
rapid route to code that does not work correctly and introduces security
holes.


I agree completely but, and sorry if I'm missing something, the labs() 
function could still be required to return LONG_MIN if passed LONG_MIN, 
correct? It's just that the implementation changes from:


   long labs(long i)
   {
    return (i > 0) ? i : -i;
   }


to, for example:

   long labs(long i)
   {
    if (i == LONG_MIN) return LONG_MIN;
    return (i > 0) ? i : -i;
   }


(which is potentially compiled to the same thing, though a brief test 
shows current compilers fail to do that).


So, this POSIX requirement doesn't actually impose any extra 
requirements on the C compiler, if I understand correctly - just on the 
implementation of the abs() functions.

Re: About issue 0001108 and abs(INT_MIN)

[Joseph Myers]

On Thu, 19 Jul 2018, Joerg Schilling wrote:

> Since the C++ people already think about making this to happen in ther next 
> standard, it seems that the C compilers may do something similar in the 
> future.

The latest version of the C++ proposal 
 is 
clear that it does not change undefined overflow (while adding the new 
constraint to representations to reflect more or less universal existing 
practice in that regard).  I quote:

Status-quo If a signed operation would naturally produce a value that 
is not within the range of the result type, the behavior is undefined. 
The author had hoped to make this well-defined as wrapping (the 
operations produce the same value bits as for the corresponding 
unsigned type), but WG21 had strong resistance against this.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: About issue 0001108 and abs(INT_MIN)

[Joseph Myers]

On Thu, 19 Jul 2018, Joerg Schilling wrote:

> Signed integer overflow can only trigger undefined behavior in case that more 
> than a single specific architecture could be envolved.

No, signed integer overflow is part of the contract between a C programmer 
and the implementation.  A C programmer guarantees to the implementation 
that the execution of their code according to the semantics of the 
abstract machine defined by the C standard will not result in undefined 
behavior, and the C implementation uses that information to optimize the 
code (for example, determining that the result of a call to abs must be 
non-negative, and that the product of two non-negative signed integers 
must be non-negative, because by using signed operations the programmer 
has given those guarantees to the implementation).

C semantics are always those of the high-level language as defined by the 
standard, not those of particular machine instructions for the 
architecture in use; there hasn't really been a correspondence to machine 
instruction semantics for decades.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
https://blog.regehr.org/archives/213

(and see parts 2 and 3 of both those posts as well).  This is critical 
understanding for any systems-level C programmer in the modern world; the 
optimizations are not new, but have been around for decades in major 
implementations.

> Since POSIX de-facto only allowed two's complement machines since several 
> years 
> already (the current change is just fixing the slipped parts in the 
> standard), 
> it is now well defined what happens in case of an integer overflow.

No, it is very definitely undefined.  It's true that anyone programming in 
C on POSIX systems for about the past 20 years has probably in fact only 
needed to care about two's complement systems.  But it's also true that 
programming in C for about the past 20 years without a proper modern 
understanding of undefined behavior as discussed in the above blog posts 
(or otherwise avoiding anything the C standard says is undefined) is a 
rapid route to code that does not work correctly and introduces security 
holes.

All that's meant by two's complement, as far as C is concerned, is certain 
constraints on what the byte representations of integers look like, if you 
inspect or modify those representations using lvalues of type unsigned 
char (which is a legitimate thing to do in standard C).  It in no way 
constrains overflow behavior.  The same implementations that have been 
ubiquitously two's complement for the past 20 years have also been 
ubiquitously optimizing on the basis of undefined signed integer overflow 
for the past 20 years.

POSIX is generally meant to standardize existing APIs rather than invent 
things that haven't been tried in practice.  That makes it entirely 
appropriate to require two's complement representation (and thus two's 
complement sets of values for signed integer types) rather than attempting 
to come up with a purely-invented specification for how certain interfaces 
would work with other historical integer representations.  But it also 
makes it entirely *inappropriate* to invent specifications for functions 
such as abs that are contrary to well-established implementations practice 
for those functions over the past few decades.  The specification in this 
issue8-tagged issue is such a completely inappropriate and ill-thought-out 
invention taking no account of very longstanding implementation practice 
and providing no benefits to users.

If POSIX wishes to provide a mode that profiles the C standard to define 
certain cases of signed integer overflow that are otherwise undefined, it 
should standardize the -fwrapv compiler flag (using that existing, de 
facto standard, spelling).  In accordance with existing practice, that 
mode should not be the default.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: About issue 0001108 and abs(INT_MIN)

[Joerg Schilling]

Joseph Myers  wrote:

> On Mon, 16 Jul 2018, Vincent Lefevre wrote:
>
> > As expected, the text in http://austingroupbugs.net/view.php?id=1108
> > makes Debian's c99 utility behave incorrectly. FYI, I've reported a
> > bug:
>
> While I think the changes proposed for issue8 are wrong, they clearly 
> can't result in a bug in any c99 utility, since issue8 will surely have a 
> corresponding utility for a later version of the C standard, and not a c99 
> utility at all.

Signed integer overflow can only trigger undefined behavior in case that more 
than a single specific architecture could be envolved.

Since POSIX de-facto only allowed two's complement machines since several years 
already (the current change is just fixing the slipped parts in the standard), 
it is now well defined what happens in case of an integer overflow.

Since the C++ people already think about making this to happen in ther next 
standard, it seems that the C compilers may do something similar in the future.

There is a small difference: C is being used for more platforms than just a 
POSIX OS. The integer overflow related warnings may be needed for other targets 
and could be switched on in case that the compiler is called with flags that 
refer to non-POSIX embedded targets.



Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: About issue 0001108 and abs(INT_MIN)

[Joseph Myers]

On Mon, 16 Jul 2018, Vincent Lefevre wrote:

> As expected, the text in http://austingroupbugs.net/view.php?id=1108
> makes Debian's c99 utility behave incorrectly. FYI, I've reported a
> bug:

While I think the changes proposed for issue8 are wrong, they clearly 
can't result in a bug in any c99 utility, since issue8 will surely have a 
corresponding utility for a later version of the C standard, and not a c99 
utility at all.

-- 
Joseph S. Myers
jos...@codesourcery.com

About issue 0001108 and abs(INT_MIN)

[Vincent Lefevre]

As expected, the text in http://austingroupbugs.net/view.php?id=1108
makes Debian's c99 utility behave incorrectly. FYI, I've reported a
bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903771

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)