fyi
0 N035!!!!
Guess I’d better get Windows 7 pretty quick, then.
BFL
Well, what do you expect from something coded in C/C++?
The problem is partly caused by the coder, partly by the compiler optimization.
The typical code fragment goes like this:
struct sock *sk = tun->sk;
(probably some more declarations and stuff)
if (!tun)
return POLLERR;
The compiler, seeing that the pointer ‘tun’ has already been read, assumes that the check for “!tun” (which would be the same as “tun != 0”) is redundant. This, however, isn’t true - the dereference to tun->sk would have returned gibberish if tun were == 0.
The solution is to put the dereference of tun->sk after the check.
A better solution would be for compilers to emit an error message when a pointer that has not been assigned a value is dereferenced - as in better, more strongly typed languages like Ada.
It would be nice, tho, if all compilers based on the gcc/GNU toolchain could somehow emit a log of “this is what I did in the optimization phase” with the original source (not just the generated asm code) so that the programmer had some clue of changes being made to the code. In the old days, when the PL/I optimizing compiler was all the rage on IBM machines (the late 70’s and early 80’s), we had a joke “Does it.... or doesn’t it? Only your PL/I OPT compiler knows for sure” — because the damn compiler re-wrote so much code on the fly for you.
Another hyper-optimizing compiler that left more than one person scratching their head was the FORTH1 FORTRAN compiler on IBM machines - and Bliss-32 on VAX systems.