[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200701221950.l0MJoLxb012499@turing-police.cc.vt.edu>
Date: Mon, 22 Jan 2007 14:50:21 -0500
From: Valdis.Kletnieks@...edu
To: Marcin Owsiany <marcin@...iany.pl>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 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 way?
> (Somehow I feel that the answer is that not all CPUs do that, so - no.)
The fact that some CPUs implement overflow detection in ways best described
as byzantine and sometimes merely flawed or lacking entirely is why C does
such hand-waving on the issue. 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 programmer code tests when actually needed.
You think it's bad *now*, where you have to force-feed a 2-billion-something
value in to cause an integer overflow, you obviously aren't old enough to have
programmed on 16-bit machines, where numbers around 32,000 were sufficient,
and even 'unsigned int' didn't suffice to let you sort 5-digit US postal ZIP
codes...
(And we won't mention the horrorshow that was floating point before IEEE-standard
became widely used...)
Content of type "application/pgp-signature" skipped
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists