I never thought that I'd be directly hit by an IE bug. However, it happened today. This page:
http://www.hex-rays.com/compare.shtml
does not render correctly in IE7. I tried everything, got rid of all validator complaints, rearranged the code, played with the css file, and finally checked the IE bug collections.
Okay, I give up.
Where should I submit the bug or seek help?
A quite interesting document for everyone who programs in C++:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
I'm even tempted to switch to it when/if it becomes available.
Quite often I have to revise old code in IDA Pro. Given its age, it happens almost every time a new feature is added (two exceptions: the bTree and the virtual memory manager are basically the same as about 17 years ago).
There is no such thing as a bug free software. Today I stumbled on this:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
This is an unfortunate and sad truth about programming: regardless of our efforts, software will have bugs; it will crash, it will burn, it will fail. At the same time there is a hope:
We desperately need code verification tools like this.
Quite busy week, sorry for being silent.
I wanted to talk about an annoyance I discovered with all my C/C++ compilers.
Here is quite interesting presentation from Halvar Flake:
Attacks on uninitialized local variables
After reading it I wanted to verify my compilers and created a small C file. I wanted to check if the compilers would warn me of a potential uninitialized variable. The source code was pretty simple:
void const_ptr_acceptor(const int *);
int control_func(void)
{
int x;
return x + 1; // compiler emits a warning
}
int check_func(void)
{
int x;
const_ptr_acceptor(&x); // we do not modify x here!
return x + 1; // compiler does not emit a warning
}
We have two functions, they both use an uninitialized variable. The only difference is the call to const_ptr_acceptor() which promises not to modify 'x'. I compiled this source code with all warnings turned on. I was expecting two warnings from the compiler: the first warning about 'control_func' and the second warning about 'check_func'. However, there was only one warning:
E:\hex\const_ptr>cl /Wall /c const_ptr.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50215.44 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
const_ptr.cpp
e:\hex\const_ptr\const_ptr.cpp(6) : warning C4700: uninitialized local variable 'x' used
I tried with all available compilers, but they were unanimous in their behavior: as soon as we pass a pointer to a variable, the compiler thinks that it is initialized. We explicitly specify with the const specifier that the function does not modify the variable, but the compilers seems to ignore it.
I compiled the code with Microsoft Visual Studio, Borland BCB6, GNU C, Intel compilers.
Still have no explanation why all compilers behave this way.
FOSDEM did not deceive me at all - just the contrary.
There were many interesting things and the talk I liked the most was about valgrind. The very obvious idea after it was "why not develop a security scanner on the top of valgrind?". Valgrind is a framework to develop simulation-based tools, and MemCheck is just one of them. Valgrind handles the most tedious and demanding part of the job - simulating the processor instructions. It also handles the operating system calls, signals, and the rest, so the developer of a security scanner will be able to concentrate on the essential things.
Just an idea..
Textbooks on software engineering prescribe to check preconditions at the beginning of a function. This is a really good idea: the sooner we detect that the input data or environment does not match our expectations, the easier it is to trace and debug the application. A nice function with precondition checking refuses to "work" if the preconditions are not satisfied.
The last week Ero Carrera in his blog linked to this spectacular site:
The IDA Pro book