Re: A C++ Whishlist

From: Ram Firestone (bichir_at_covad.net)
Date: 03/19/04 

Date: 18 Mar 2004 23:49:55 -0800

Kevin Goodsell <usenet2.spamfree.fusion@neverbox.com> wrote in message news:<CTr6c.28277$%06.19752@newsread2.news.pas.earthlink.net>...
> Ram Firestone wrote:
> > Kevin Goodsell <usenet2.spamfree.fusion@neverbox.com> wrote in message news:<YWj6c.27591$%06.991@newsread2.news.pas.earthlink.net>...
> >
> >>Ram Firestone wrote:
> >>
> >>>As I said elsewhere. What are you going to do when you catch all these
> >>>null pointers.
> >>
> >>Uh... signal an error, maybe?
> >>
> >
> >
> > Which typically happens for free anyway.
> >
>
> Show me where it says that in the standard.
>

It's not in any standard. It just does.

> >
> >>>In most cases the only thing you can do is crash
> >>>slightly more gracefully. This often screws up your core and now you
> >>>have a harder time debugging the problem.
> >>
> >>That is certainly not what happens in my code. In fact, this can
> >>logically only happen in *your* version - you are the one invoking
> >>undefined behavior.
> >
> >
> > You can live in a fantasy world if you wish but I think you would have
> > a hard time finding a modern computer that doesn't generate a fault on
> > NULL pointer reference.
> >
>
> I don't even need to look. I've programmed systems like that. You'd be
> surprised (apparently) how many architectures have address 0 as a
> perfectly valid memory address, and also use it to represent a null
> pointer (because it's easy, and there may not be a more appropriate
> address anyway). All the world is not a desktop system.
>

Ok name some. Yeah I would be surprised how many. Let's see not Lunix,
Windows, IBM workstation, mainframe, HP/UX ..... I'm really curious.
And please don't say PDP-8 because it's not exactly modern. In any
case once you find one you will then have to find a compiler on that
system that doesn't pass NULL to members in order for your argument to
have any relevance to this thread.

> >
> >
> >>This
> >>makes locating the bug at least an order of magnitude easier than if the
> >>program just crashes.
> >>
> >
> >
> > Why. I can bring up the debugger on the core or just run the code in
> > the debugger and tell you the same thing. I don't need to slow down my
> > code either.
>
> Sure, maybe. But not all systems create core files. What happens when
> your Mars rover's computer crashes? And this is assuming your program
> crashes at all, instead of doing some weird random thing (undefined
> behavior is undefined, it doesn't mean the program has to crash).
>

Gee I belive I've answered the weired ramdom thing case about three
times now.

> And what does your client do if your program crashes? At least mine can
> tell me where the error occurred.
>

If you want to check every parameter at the cost of speed, be my
guest. I'm not even going to say it's wrong. What I am going to say is
unless you also check the this pointer you aren't checking every
parameter and you can still get a crash which is the whole point.

> >>
> >>Again, speed is completely irrelevant if the results are incorrect. I
> >>can easily write a program that runs in 1/1000000th the time yours runs
> >>in if the answer doesn't have to be right.
> >>
> >
> >
> > Except your program will fail at the same rate as mine.
>
> I doubt that.

Just because you check for unrecoverable errors doesn't make them
happen less. All it means is you may print a better message. But wait
you aren't checking the this pointer.

>
> > All you
> > typically get for your work is cute error message. It may or may not
> > be more informative depending on how you implement it but your user
> > isn't going to care, if he sees "dereference of NULL pointer line 467
> > file foo.cpp" or "Segmentation violation". For him the program still
> > failed.
>
> And he can tell me *where* it failed, so I can fix it. What can your
> user do? Other than find another software vendor, not much.
>

Sorry but in my experience the user doesn't care about the line or
file. If he even writes it down you are lucky. The frequency of
crashes is what's going to loose you customers. In my case lack of
speed will also loose me customers. In any case if he does have a core
I will be able to find out much more about the crash then you will.

> > At the same time if you were to do these checks everywhere
> > your program could be running significantly slower.
> >
>
> How much difference do you really think this will make? Have you timed
> it? If I really needed to, I would put these checks in a debug version
> and exclude them from the "real" version once they become unnecessary
> (if the errors appear to never be triggered).
>

Checking every member of every parameter for correctness would waste
huge amounts of time. Why would you stop at just checking for NULL
pointers? On many architectures you loose the pipelineing when you do
an if.

> But I'd say 98% of the time it's worth it to have the extra checks. I
> might, for example, set up my program to do whatever it can to save the
> user's data in the event of an error - even an unrecoverable logic
> error. Or the exception could abort the current operation (and provide
> some details about what happened) without killing the whole program. In
> general, optimizing by removing safeguards is a bad policy, and won't
> improve performance much.

Hey go wild. That isn't the point of this thread. My claim is that
allowing call though NULL isn't going to change much in the real
world. In fact with your mentality you would feel you then have to
check the this pointer which would give you the kind of error checking
you say you like. As it stands now you are working under the misguided
perception that the this pointer will never be NULL.

>
> I've used too many programs written by people like you. You can write
> brittle programs that crash without reasonable diagnostics or recovery
> attempts if you want to. I'll make my programs robust. And avoid yours.
>

In reality test suits make far more difference in program reliability
than anything we have talked about here. So if you want to make your
programs robust better have large automated test suits. By the way the
Mars rover's computer did crash. I'm sure they were so so careful when
they wrote the software. The problem was it wasn't tested enough. I
just thank god they were able to fix it.

Also I'll avoid your programs too as I'm sure they run at a snails
pace. On the other hand maybe they don't do enough to have that
problem.

> By the way, you've yet to answer the point that started this discussion:
> You were defending a practice of dereferencing pointers without checking
> for NULL, and *without documenting that the function should not be
> called with a null pointer*. In other words, your function is broken by
> definition (it violates its specification), and you seem to be OK with that.
>
> -Kevin

What started this discussion is my advocating member call through
NULL. As for documentation, I would document the function to the
extent that any non-idiot programmer could use it properly. For
instance if it is supposed to write out a string it is pretty obvious
you can't pass it NULL unless NULL has some special meaning. NULL is
just one of some odd billion addresses that don't work. You are going
to document or test for the rest of them? There is no way to even know
what they are.

By the way I serious doubt you check every parameter of every function
for correctness. But hey I may be wrong.

Ram

Relevant Pages

  • Re: dereferencing memory location some time after deleting the same one
    ... The Standard says that any program that attempts to dereference ... > a pointer after the pointer has been deleted, ... memory from the kernel VM and manages the allocation of little pieces ... > He could get a crash. ...
    (comp.lang.cpp)
  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Re: Threading Model = "Both" query
    ... This C++ program also doesn't crash, ... is getting a raw interface pointer, ... the beginning calls through a dangling pointer, ... one MTA in the process the object can still live. ...
    (microsoft.public.vc.atl)
  • Re: A C++ Whishlist
    ... >>Show me where it says that in the standard. ... >>pointer (because it's easy, and there may not be a more appropriate ... allowing member function calls from null pointers. ... > I will be able to find out much more about the crash then you will. ...
    (comp.lang.cpp)
  • Re: Python less error-prone than Java
    ... Your crash can tell you that it was a null ... Your crash can tell you that you stomped over memory. ... tell the difference between null pointer and wrong type. ... but what if you somehow lose the error message and get only ...
    (comp.lang.python)