Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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 >

Re: About issue 0001108 and abs(INT_MIN)

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

RE: About issue 0001108 and abs(INT_MIN)

> -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) > > V

Re: About issue 0001108 and abs(INT_MIN)

> 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

Re: About issue 0001108 and abs(INT_MIN)

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

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 you expect. Not just recent

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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) >{ >    

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

Re: About issue 0001108 and abs(INT_MIN)

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

About issue 0001108 and abs(INT_MIN)

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: