On Sun, 21 Jan 2007 12:07:18 GMT, Marcin Owsiany said:
I also think that CPUs can detect internally when an overflow happens -
is there a way to use that feature in C somehow, in a portable way?
(Somehow I feel that the answer is that not all CPUs do that, so - no.)
The fact that some CPUs
On Mon, Jan 22, 2007 at 02:50:21PM -0500, [EMAIL PROTECTED] wrote:
It's generally considered performance-crippling
to add inline code that does a test condition/branch pair after *every
single*
opcode that might cause an overflow - so the C paradigm is to leave them out
and have the
On Mon, 22 Jan 2007 20:42:35 GMT, Marcin Owsiany said:
Actually, I'm old enough to have programmed on 8-bit machines, but we're
getting off-topic here :-)
That makes you a newbie. The 16-bit PDP-11, and the 12-bit PDP-8, and all
the rest of those weird-size machines from DEC (18, 36 bit) and a
: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Major gcc 4.1.1 and up security issue
On Sun, 21 Jan 2007 12:07:18 GMT, Marcin Owsiany said:
I also think that CPUs can detect internally when an overflow happens -
is there a way to use that feature in C somehow, in a portable
On Sun, Jan 21, 2007 at 01:20:05AM +0100, Pavel Kankovsky wrote:
This optimization (*) is ok as long as no overflow occurs during the
evaluation of the original condition. It modifies its semantics when
integer overflows are involved but this is acceptable because the result
of an
I guess something like this, but with substraction instead of division
can be implemented for checking for overflows on addition?
Personally I was very surprised that most people thought of a + 100 a
first. I never used that, however tempting it could be, because it felt like
cheating. For
On Mon, 15 Jan 2007, Felix von Leitner wrote:
int foo(int a) {
assert((int)(a+100) 0);
printf(%d %d\n,a+100,a);
return a;
}
The assert() here is quite different from the code you published on the
web where the condition reads (a+100 a).
Now you might think that it's
off topic thoughts:
(twice 1.15 will likely be a bit or two different than 3.30). As Fortran
geeks have known for over half a century, a better way to code this is:
if (abs(a-b) n*epsilon*a)
where 'epsilon' is the hardware constant defining the smallest number such
that 1+a is
On Wed, 17 Jan 2007 19:07:19 +0100, Marcus Graf said:
off topic thoughts:
(twice 1.15 will likely be a bit or two different than 3.30). As Fortran
geeks have known for over half a century, a better way to code this is:
if (abs(a-b) n*epsilon*a)
where 'epsilon' is the
Hi,
this looks strange.
I have made a test with gcc 4.03. The assertation was thrown correctly.
So, is this only with gcc 4.1?
It seems that the interpretation of the standard was in gcc 4.03
better.
~$ ./a.out
200 100
a.out: test.c:5: foo: Assertion `(int)(a+100) 0' failed.
Aborted
[EMAIL
On Mon, 15 Jan 2007 21:07:40 +0100, Felix von Leitner said:
So, in my gnupg diff, I used code like this:
assert(a+100 a);
Note that if 'a' is a macro with side effects (the ++ and -- operators are
particularly famous for this), you may just have seriously buggered the program
while trying
So, in my gnupg diff, I used code like this:
assert(a+100 a);
with a being an int. Here, have this example code:
#include assert.h
#include stdio.h
int foo(int a) {
assert((int)(a+100) 0);
printf(%d %d\n,a+100,a);
return a;
}
int main() {
foo(100);
That's an integer overflow. It's well known. See Phrack Volume 0x0b,
Issue 0x3c, Phile 0x0a for an introduction to this basic issue.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and
On 1/16/07, Resident_Geek [EMAIL PROTECTED] wrote:
That's an integer overflow. It's well known. See Phrack Volume 0x0b,
Issue 0x3c, Phile 0x0a for an introduction to this basic issue.
Felix' point was that the latest gcc breaks code that is supposed to
_detect_ integer overflows.
Cheers,
14 matches
Mail list logo
