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
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
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
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
>
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
> -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
> 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
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
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
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
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)
>{
>
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
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
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
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
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
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
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
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
19 matches
Mail list logo