Shachar Shemesh shachar at debian.org writes:
My understanding of things is that undefined behaviors are fairly
common, and almost always benign. Look at the following code:
int add( int a, int b )
{
return a+b;
}
Do you really want to get a Warning: signed
On 2014-04-15 10:17:04 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
Andrew Pinski said: For the first warning, even though the warning is
correct, I don't think we should warn here as the expressions are split
between two different statements., which is more or less
On 2014-04-15 21:57:21 +0100, Roger Lynn wrote:
The purpose of this gcc warning isn't to warn you that overflow
might happen, but to warn you when gcc's optimisations have broken
any two's complement overflow behaviour that you might have
expected. Thus if you have written code that assumes
On 2014-04-14 17:01:42 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
But what I mean is that it's pointless to emit such a warning when the
effect of the potential integer overflow is already visible, for
instance in printf below:
m = d * C;
printf (%d\n,
On Fri, 11 Apr 2014, Ansgar Burchardt wrote:
On 04/11/2014 12:42, Ian Jackson wrote:
What people expect is that the compiler compiles programs the way C
was traditionally compiled.
Actually, I think we need to go further. We need a programming
language (with at least two compiler
* Thorsten Glaser t...@mirbsd.de, 2014-04-15, 11:24:
we need to go further. We need a programming language (with at least
two compiler implementations), which I will call Ͻ, that looks like C
so much that *every* C program¹ is also a valid Ͻ program, and *every*
Ͻ program that does not make
On 15/04/14 19:45, Jakub Wilk wrote:
* Thorsten Glaser t...@mirbsd.de, 2014-04-15, 11:24:
we need to go further. We need a programming language (with at least
two compiler implementations), which I will call Ͻ, that looks like C
so much that *every* C program¹ is also a valid Ͻ program, and
Vincent Lefevre vinc...@vinc17.net writes:
The cases m = d * C and m = 0 are mostly the same, i.e. with the
same false positives in practice. So, there's no reason to provide a
warning for the second one only.
I don't think the GCC authors are just being dumb here. There probably is
a
Jakub Wilk jw...@debian.org writes:
* Thorsten Glaser t...@mirbsd.de, 2014-04-15, 11:24:
we need to go further. We need a programming language (with at least two
compiler implementations), which I will call Ͻ, that looks like C so
much that *every* C program¹ is also a valid Ͻ program, and
On 14/04/14 14:30, Vincent Lefevre wrote:
On 2014-04-14 14:14:14 +0200, Raphael Geissert wrote:
No, there is no optimisation in that case, so there is no warning. It only
warns when it uses the knowledge that (signed) integer overflow isn't
possible to optimise away some redundant code.
On 2014-04-10 14:38:46 -0700, Russ Allbery wrote:
I don't want, necessarily, to have slower code to make handling
corner cases easier. However, I am generally happy to have slower
code in return for making the system more secure, as long as the
speed hit isn't too substantial. Security is a
* Vincent Lefevre vinc...@vinc17.net, 2014-04-14, 12:56:
IMHO, in general, for security, it is better to run code with a
sanitizer (such as clang -fsanitize=undefined -fno-sanitize-recover,
assuming that the code does not use floating point),
gcc has also -ftrapv, which might be what you
On 2014-04-12 20:32:33 -0700, Russ Allbery wrote:
I enabled -fstrict-overflow -Wstrict-overflow=5 -Werror in my standard
[...]
GCC does silly things with -Wstrict-overflow=5.
For instance, consider the following code:
int foo (int d)
{
int m;
m = d * 64;
return m;
}
With gcc -O2
On 2014-04-14 13:11:12 +0200, Jakub Wilk wrote:
* Vincent Lefevre vinc...@vinc17.net, 2014-04-14, 12:56:
IMHO, in general, for security, it is better to run code with a sanitizer
(such as clang -fsanitize=undefined -fno-sanitize-recover, assuming that
the code does not use floating point),
Vincent Lefevre wrote:
[...]
int foo (int d)
{
int m;
m = d * 64;
return m;
}
[...]
while the cause of a potential bug would be the same. For consistency,
GCC should have warned for the first code too.
No, there is no optimisation in that case, so there is no warning. It only
warns
Russ Allbery wrote:
Shachar Shemesh shac...@debian.org writes:
Do you really want to get a Warning: signed integer overflow yields
undefined behavior on this function?
I would certainly like to be able to enable such a thing. I write a lot
of code where I'd love the compiler to
On 2014-04-14 14:14:14 +0200, Raphael Geissert wrote:
Vincent Lefevre wrote:
[...]
int foo (int d)
{
int m;
m = d * 64;
return m;
}
[...]
while the cause of a potential bug would be the same. For consistency,
GCC should have warned for the first code too.
No, there is
On 14.04.2014 14:26, Raphael Geissert wrote:
Russ Allbery wrote:
Shachar Shemesh shac...@debian.org writes:
Do you really want to get a Warning: signed integer overflow yields
undefined behavior on this function?
I would certainly like to be able to enable such a thing. I write a lot
of
Vincent Lefevre vinc...@vinc17.net writes:
But what I mean is that it's pointless to emit such a warning when the
effect of the potential integer overflow is already visible, for
instance in printf below:
m = d * C;
printf (%d\n, m);
return m = 0;
If there was an integer overflow,
On 13/04/14 06:32, Russ Allbery wrote:
Like I said before, I am not against the compilers warning about such
cases. I just think that these warnings need to be done very carefully,
or they become worse than useless. As such, if you see a case in which
you feel gcc (or clang, or whatever)
On Thu, 10 Apr 2014, Shachar Shemesh wrote:
I never did understand what people expect. gcc uses the undefined
Warn the hell out of any line of code with per-spec undefined behaviour, if
not by default, at least under -Wall.
THAT would be a good start. Too bad not even gcc knows every time it
On 12/04/14 23:38, Henrique de Moraes Holschuh wrote:
On Thu, 10 Apr 2014, Shachar Shemesh wrote:
I never did understand what people expect. gcc uses the undefined
Warn the hell out of any line of code with per-spec undefined behaviour, if
not by default, at least under -Wall.
I have no
Shachar Shemesh shac...@debian.org writes:
I will point out that it is not always is possible, and is quite often
not easy. For example, the famous undefined after NULL dereference
would probably cause a warning every time a function uses a pointer it
was given without first validating its
On 13/04/14 05:39, Russ Allbery wrote:
One can make a good argument that such checks are exactly what you should
be doing.
Then the answer is very simple. Write in Java.
My understanding of things is that undefined behaviors are fairly
common, and almost always benign. Look at the following
Shachar Shemesh shac...@shemesh.biz writes:
On 13/04/14 05:39, Russ Allbery wrote:
One can make a good argument that such checks are exactly what you
should be doing.
Then the answer is very simple. Write in Java.
There are a lot of reasons other than the absolute fastest performance you
Shachar Shemesh writes (Re: Having fun with the following C code (UB)):
I never did understand what people expect.
What people expect is that the compiler compiles programs the way C
was traditionally compiled.
Obviously that expectation nowadays results in disappointment, and
isn't captured
Hi,
On 04/11/2014 12:42, Ian Jackson wrote:
Shachar Shemesh writes (Re: Having fun with the following C code (UB)):
I never did understand what people expect.
What people expect is that the compiler compiles programs the way C
was traditionally compiled.
Shouldn't -O0 come close
On 11/04/14 13:49, Ansgar Burchardt wrote:
Hi,
On 04/11/2014 12:42, Ian Jackson wrote:
What people expect is that the compiler compiles programs the way C
was traditionally compiled.
Shouldn't -O0 come close to that expectation?
I think that Ansgar's answer is spot on, but against all good
On Thu, Mar 27, 2014 at 09:07:14AM +0100, Mathieu Malaterre wrote:
Here is a little bug I just discovered:
http://stackoverflow.com/questions/22664658/finding-off-t-size
For reference, here are the packages affected in debian:
http://codesearch.debian.net/search?q=LARGE_OFF_T
For
* Wouter Verhelst wou...@debian.org, 2014-04-10, 12:03:
I've had to figure out the size of off_t in nbd-server, and have been
doing it without relying on overflow, for years now. It took quite a
few iterations to get it right, but the current definition has looked
like this since 2006:
On Thu, Apr 10, 2014 at 12:29:50PM +0200, Jakub Wilk wrote:
* Wouter Verhelst wou...@debian.org, 2014-04-10, 12:03:
I've had to figure out the size of off_t in nbd-server, and have been
doing it without relying on overflow, for years now. It took quite a few
iterations to get it right, but the
Wouter Verhelst writes (Re: Having fun with the following C code (UB)):
Yes; the standard does this to allow for machine architectures which do
not use two's complement to store negative values. I did mention that
assumption in my previous mail.
If the architecture uses two's complement
Ian Jackson dixit:
If the architecture uses two's complement, however, then the code is
correct.
Unfortunately adversarial optimisation by modern compilers means that
this kind of reasoning is no longer valid.
The compiler might easily see that your code unconditionally performs
a computation
On 2014-04-10 12:42:03 +0200, Wouter Verhelst wrote:
On Thu, Apr 10, 2014 at 12:29:50PM +0200, Jakub Wilk wrote:
* Wouter Verhelst wou...@debian.org, 2014-04-10, 12:03:
I've had to figure out the size of off_t in nbd-server, and have
been doing it without relying on overflow, for years
* Wouter Verhelst wou...@debian.org, 2014-04-10, 12:42:
I've had to figure out the size of off_t in nbd-server, and have been
doing it without relying on overflow, for years now. It took quite a
few iterations to get it right, but the current definition has looked
like this since 2006:
On 2014-04-10 11:48:44 +, Thorsten Glaser wrote:
Ian Jackson dixit:
If the architecture uses two's complement, however, then the code is
correct.
Unfortunately adversarial optimisation by modern compilers means that
this kind of reasoning is no longer valid.
The compiler might
Vincent Lefevre writes (Re: Having fun with the following C code (UB)):
On 2014-04-10 11:48:44 +, Thorsten Glaser wrote:
And GCC is a repeat offender which actually does do that.
If you don't like that, you should use the -fwrapv option.
Sadly that doesn't deal with all
On 10/04/14 20:59, Ian Jackson wrote:
Vincent Lefevre writes (Re: Having fun with the following C code (UB)):
On 2014-04-10 11:48:44 +, Thorsten Glaser wrote:
And GCC is a repeat offender which actually does do that.
If you don't like that, you should use the -fwrapv option.
Sadly
Shachar Shemesh shac...@debian.org writes:
I never did understand what people expect. gcc uses the undefined
behavior to not emit checks it would otherwise have to, so that your
code runs faster. This affects not only those corner cases, where you
are relying on this behaving a certain way,
On Fri, Apr 11, 2014 at 5:38 AM, Russ Allbery wrote:
I don't want, necessarily, to have slower code to make handling corner
cases easier. However, I am generally happy to have slower code in return
for making the system more secure, as long as the speed hit isn't too
substantial. Security
On Thu, 27 Mar 2014, Jakub Wilk wrote:
* Mathieu Malaterre ma...@debian.org, 2014-03-27, 13:06:
I preferred not to mass bug everyone out there and instead:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780
But many packages don't regenerate autofoo at build-time. :-(
LFS is still
Here is a little bug I just discovered:
http://stackoverflow.com/questions/22664658/finding-off-t-size
For reference, here are the packages affected in debian:
http://codesearch.debian.net/search?q=LARGE_OFF_T
For reference clang fails as was expected by the initial author, but
recent gcc
On Thu, Mar 27, 2014 at 9:07 AM, Mathieu Malaterre ma...@debian.org wrote:
Here is a little bug I just discovered:
http://stackoverflow.com/questions/22664658/finding-off-t-size
For reference, here are the packages affected in debian:
http://codesearch.debian.net/search?q=LARGE_OFF_T
While
On Thu, Mar 27, 2014 at 01:06:02PM +0100, Mathieu Malaterre wrote:
Here is a little bug I just discovered:
http://stackoverflow.com/questions/22664658/finding-off-t-size
For reference, here are the packages affected in debian:
http://codesearch.debian.net/search?q=LARGE_OFF_T
On Thu, Mar 27, 2014 at 1:19 PM, Andrey Rahmatullin w...@wrar.name wrote:
On Thu, Mar 27, 2014 at 01:06:02PM +0100, Mathieu Malaterre wrote:
Here is a little bug I just discovered:
http://stackoverflow.com/questions/22664658/finding-off-t-size
For reference, here are the packages
* Mathieu Malaterre ma...@debian.org, 2014-03-27, 13:06:
I preferred not to mass bug everyone out there and instead:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780
But many packages don't regenerate autofoo at build-time. :-(
LFS is still a release goal, not a requirement.
Then
On Thu, Mar 27, 2014 at 2:50 PM, Jakub Wilk jw...@debian.org wrote:
* Mathieu Malaterre ma...@debian.org, 2014-03-27, 13:06:
I preferred not to mass bug everyone out there and instead:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780
But many packages don't regenerate autofoo at
Does
Le 27 mars 2014 15:05, Mathieu Malaterre ma...@debian.org a écrit :
On Thu, Mar 27, 2014 at 2:50 PM, Jakub Wilk jw...@debian.org wrote:
* Mathieu Malaterre ma...@debian.org, 2014-03-27, 13:06:
I preferred not to mass bug everyone out there and instead:
* Mathieu Malaterre ma...@debian.org, 2014-03-27, 15:04:
I preferred not to mass bug everyone out there and instead:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780
But many packages don't regenerate autofoo at build-time. :-(
And your point is ?
That they won't immediately
49 matches
Mail list logo
