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.
Attachment:
signature.asc
Description: Digital signature