* Code Audit Labs: > that's funny, the above code still can be bypassed because of > incorrect check order. > > and example code > calloc(0x10000001, 0x10); > > it will return NULL in winxp or gligc 2.5 > it will return 0x10 sizes heap in glibc <2.5(maybe prior) or > win2000 sp4 This bug has been fixed in GNU libc CVS in August 2002. I've just checked version 2.3.6, and it does return NULL on overflow. There is, however, a different version of calloc that GDB sees, but this is not the real one invoked by application code. On Windows, this bug depends on the Microsoft Visual C++ run-time library. As a result, it's not completely determined by the Windows version alone. By the way, the similar operator new[] issue that has been reported in conjunction with that calloc issue: <http://cert.uni-stuttgart.de/advisories/calloc.php> has allegedly been fixed by Microsoft as well, by throwing std::bad_alloc. G++ and libstdc++ are still vulnerable to applications that perform unbounded allocations. Over the years, it's been debated again and again what the C++ standard says on this matter, how large the performance impact would be, and so on, but no one has created a patch (which would need to change the cross-vendor C++ ABI, too). The Ada Reference Manual does not preclude a fix, but I don't think anyone has written a patch for GNAT.
