www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Integer overflow bug in windows

reply Kagamin <spam here.lot> writes:
http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx
Nov 09 2011
next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 09.11.2011, 22:34 Uhr, schrieb Kagamin <spam here.lot>:


 http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


Solution: upgrade all computers to 64-bit
Nov 09 2011
parent reply Kagamin <spam here.lot> writes:
Marco Leise Wrote:


 Am 09.11.2011, 22:34 Uhr, schrieb Kagamin <spam here.lot>:
 

 http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


 
 Solution: upgrade all computers to 64-bit


In windows ULONG is used for reference count, which is still 32-bit on 64-bit
system.
Nov 09 2011
parent reply Kagamin <spam here.lot> writes:
 Solution: upgrade all computers to 64-bit


 
 In windows ULONG is used for reference count, which is still 32-bit on 64-bit
system.


Although 32-bit counter may prove to be inadequate for 64-bit address space.
Nov 09 2011
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 10.11.2011, 05:21 Uhr, schrieb Kagamin <spam here.lot>:


 Solution: upgrade all computers to 64-bit


 In windows ULONG is used for reference count, which is still 32-bit on  
 64-bit system.


 Although 32-bit counter may prove to be inadequate for 64-bit address  
 space.


I was only half serious about that ;) Clearly they had a bug with their  
reference counter not decrementing in a certain situation.
Nov 10 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Kagamin:


 http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


I'd like a runtime error when an integral overflows (unsigned numbers too, the
C99 Standard is not a religion book for me), unless where asked otherwise.

Bye,
bearophile
Nov 09 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 09-11-2011 23:49, bearophile wrote:

 Kagamin:


 http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


 I'd like a runtime error when an integral overflows (unsigned numbers too, the
C99 Standard is not a religion book for me), unless where asked otherwise.

 Bye,
 bearophile



blocks.

- Alex
Nov 09 2011
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 10.11.2011, 00:07 Uhr, schrieb Alex R=C3=B8nne Petersen  =

<xtzgzorex gmail.com>:


 On 09-11-2011 23:49, bearophile wrote:

 Kagamin:


 http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-expl=






oitability-of-ms11-083.aspx

 I'd like a runtime error when an integral overflows (unsigned numbers=




  =


 too, the C99 Standard is not a religion book for me), unless where  =





 asked otherwise.

 Bye,
 bearophile





c  =


 blocks.

 - Alex


I know that the article was meant to start this discussion, but no check=
ed  =

arithmetic could have found this bug while debugging. And if it the chec=
k  =

is kept even in release mode - which is untypical for asserts - the  =

question is, if an exception or termination of the program would have be=
en  =

handled gracefully.

On the other hand I wouldn't mind checked arithmetic, especially since  =

there are assembly instructions like JO. Could this also be used to  =

execute a different branch when an overflow occurs? I mean: Would some  =

code become faster and cleaner? I am so used to not having any checking =
 =

that I cannot remember any such cases from the top of my head.

In any case blocks are the way to go, because the overflow flag is  =

manipulated by too many instructions as to just write "if (overflow())  =

{...}" after a statement. I don't know if we always want an Exception as=
  =
Nov 10 2011