MSDN FLASH IRELAND - INTERNATIONAL RESOURCES - 18 DECEMBER 2008

Microsoft Ireland Blog — Thu, 18 Dec 2008 22:07:47 GMT

a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}

re: SafeInt Compiles on gcc!

Niels Dekker — Fri, 28 Nov 2008 01:21:38 GMT

Thanks for naming me so many times, David! :-) I think that SafeInt is a _very_ useful tool, helping to write code correctly, and increasing software security. So I hope it will be widespread, on many platforms... Here at the LKEB Division of Image Processing, LUMC, Leiden (www.lkeb.nl), we develop software for both Windows and Linux, so it's very important for us to have SafeInt GCC compliant.

Kind regards, Niels

re: SafeInt Compiles on gcc!

int19h — Wed, 26 Nov 2008 11:00:28 GMT

> The Visual Studio compiler will do the right thing if you're dealing with a native type – like unsigned int – and go ahead and discard the cast and modify the argument as you'd expect.

Surely, if it does not behave according to the Standard, it's not doing "the right thing"?

[dcl] It's often the case that a standard either allows some room for interpretation, or diverging from it slightly is really a desirable outcome. For example, the RFC for FTP requires support for redirecting the data stream to a 3rd server. This used to have a real use. Now it is used for attacking people and no one implements it any more - haven't for years.

In this case, you wrote a function taking a non-const reference, which you clearly meant to be modified. There isn't any scenario I can think of where you'd really have wanted the temp copy to be modified. As I pointed out, I do think it is a serious flaw that you don't get a warning out of this, but I can't argue that ignoring a no-op cast to a simple type is really a problem. My review of the standard does not show an explicit statement (see section 8.3.2) of exactly how this ought to behave, though one could argue that the casting specification does provide that a temp value ought to be created, but nowhere does it say how a temp value passed as a reference ought to behave. If there is lack of clear guidance from the standard, then it is reasonable to expect behavior to be implementation dependent, which we as programmers would like to avoid, but I can't criticize an implementation for trying to capture programmer intent. As it turns out, the Microsoft compiler does complain if you disable the Microsoft extensions, so this is reasonable. As I stated, I do believe that we should get a warning over this, as the behavior with complex types is not what a programmer would expect. Additionally, the standard ought to make this behavior explicit (IMHO, it should be an error).

infoblog » SafeInt Compiles on gcc!

infoblog » SafeInt Compiles on gcc! — Wed, 26 Nov 2008 07:16:40 GMT

PingBack from http://blog.a-foton.ru/index.php/2008/11/26/safeint-compiles-on-gcc/