Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c

[Rob Landley]

On Friday 04 January 2008 11:29:27 Markus Hitter wrote:
> Am 03.01.2008 um 15:02 schrieb Paul Brook:
> > Having to check every return value is extremely tedious and (as
> > you've proved)
> > easy to miss.
>
> Checking every return value is a measure for programming reliable code.

There's an old tounge-in-cheek programming rule: "Never test for an error 
condition you don't know how to handle."  An example of "ha ha, only 
serious".

Not only is defensive programming a huge source of bloat, but I've had to deal 
with a lot of programs where what broke _was_ some defensive check, and the 
code would have worked just fine if they just hadn't been so paranoid.  (So 
the return value of close() is nonzero.  What do you _do_ about it?  Calling 
abort() is not necessarily the sane response.)

I've got a shell script where bash spits out an error from an
  EVVVAR="$(thing | thing2)"
construct, despite getting the right answer.  Why?  Because thing2 exits after 
consuming all its data, and the left half of the pipeline outlives it by a 
milisecond or so and then errors out when it tries to flush and close stdout 
(which has already delivered all its data, but it gets an error return from 
doing this anyway and darn it, it's going to tell you about it!)

I think that to shut it up I need to rephrase it as:
  ENVVAR="$(thing 2>/dev/null | thing2)"
but to be honest, I haven't bothered.

> > If the allocation fails we don't have any viable alternatives, so
> > we may as well stop right there.
>
> Stop != segfault? What about a meaningful exit message? What if the
> code doesn't segfault but runs havok?

On modern operating systems, allocations only return zero when you exhaust 
virtual memory.  Returning nonzero doesn't mean you have enough memory, 
because it's given you a redundant copy on write mapping of the zero page and 
will fault in physical pages when you write to 'em, which has _no_ return 
value.  Instead, the out of memory killer will shoot your program in the head 
in the middle of it's run, and your only indication of a real out of memory 
status is "kill -9".

So on a modern system, defensive programming is also somewhat futile.

Just FYI.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.