The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1196
==
Reported By:osoong
Assigned To:
> 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 following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1117
==
Reported By:geoffclare
Assigned To:
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1116
==
Reported By:geoffclare
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1115
==
Reported By:Florian Weimer
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1115
==
Reported By:Florian Weimer
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1115
==
Reported By:Florian Weimer
Assigned To:
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1115
==
Reported By:Florian Weimer
Assigned To:
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1114
==
Reported By:Florian Weimer
Assigned To:
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1114
==
Reported By:Florian Weimer
Assigned To:
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
21 matches
Mail list logo
