Robert Baron wrote: > struct tun_struct *tun=....; > struct sock *sk = tun->sk; > if(*tun) return POLLERR; > > The check to see that tun is non-null should occur before use, as in - > quite frankly it is useless to check after as tun cannot be the null > pointer (the program hasn't crashed): In Debian the default runtime environment does not map the zero page. Therefore accessing the zero page will produce a segfault. On Debian the above would be trapped at runtime. But that isn't the default on every system. In particular in classic legacy Unix systems the zero page was typically mapped and available. In those systems the zero page is initially bit-zero and reading from the zero point will return zero values from the contents there. If the program writes to the zero page then subsequent reads will return whatever was written there. This is bad behavior that was the default due to bugs in much legacy software. Unmapping the zero page will cause those programs to segfault and therefore the vendors default to having the page mapped to avoid support calls from their customers. man ld (on HP-UX) -z Arrange for run-time dereferencing of null pointers to produce a SIGSEGV signal. (This is the complement of the -Z option. -Z is the default.) -Z This is the default. Allow run-time dereferencing of null pointers. See the discussions of -Z and pointers in cc(1). (This is the complement of the -z option.) This is one of the areas that needs to be addressed when people port software developed on a legacy Unix system over to a GNU/Linux system. If the software wasn't written with this in mind then it might be buggy and will need runtime testing to verify it. Thankfully today the culture has changed and test driven development is much more the good development paradigm and the zero page is unmapped by default. > I am under the impression that these problems are rather widely known among > c programmers (perhaps not the kids fresh out of college). But this is why > teams need to have experienced people. I can only say, yes, of course. :-) > Furthermore, it is very common to find code that works before optimization, > and fails at certain optimization levels. Recently, I was compiling a > library that failed its own tests under the optimization level set in the > makefile but passed its own test at a lower level of optimization. Optimizer bugs have been known for as long as there have been optimizers. There isn't anything new here. Bob P.S. On a project I worked on I had a hard time convincing the team that we should turn on the ld -z option for our project so as to find these types of bugs. It was counter culture to take this type of action! They didn't want it to have a crash at run time. They didn't have any culture of testing in development. The only test was in the live run of the program by customers. Therefore it would mostly be the customers who would experience the crash. I had to promise that I would personally react quickly and chase down any of these bugs that were found.
Description: Digital signature