Testing if a pointer is valid

[Rui Maciel]

With the bicycle analogy, trying to dereference a null pointer is like
getting stopped by the police whereas dereferencing a dangling pointer
is more like running into a china shop with malfunctioning breaks.

Not quite. C's "bicycle breaks" do work quite well. The only issue is that
the person riding the bicycle must know how to use them. If he is so bad at
it that he runs into the figurative china shop then he can only complain
about himself and his lack of skills.

As it is often said, a bad workman always blames his tools.


Rui Maciel

 

[jacob navia]

Le 21/09/11 18:00, Kenneth Brody a écrit :

Well, what do you do in (2) after displaying the dialog? Abort? Return
an error? Something else?

Abort, Retry, Ignore?
Then the user chooses what to do.

In non interactive programs you log that into the log file
and depending onthe recovery strategy either you abort,
you jump to a restart point, or you return from the
function.

And, how does (2) help you determine the caller, and track down why it
was called with a bad argument?

Because of the informative eror message of course, that tells you
what library function received the bad argument, the program counter,
etc.

 

[jacob navia]

Le 21/09/11 18:26, Kenneth Brody a critic :

The problem with trying to make idiot-proof software is that the
universe keeps creating better idiots.

Nothing you can do (that I can think of) can be 100% failsafe in
checking that the pointer is "valid".

Nobody wants to do that. I told you already that this is not
a magical solution to all problems. It s just a BETTER solution
under certain circumstances that can give more meaningful
error messages than

bus error
core dumped.

And, (embedded programmers should know) not all CPUs have
a MMU that will crash... Many will just overwrite some
other process memory or whatever

 

[Rui Maciel]

You seem to be equating "unsafe" with bad. In fact, no such moral
judgement is being made.

In this specific case I'm equating bad as being bad. If someone fails to
consider an object's lifetime when designing code which assigns a pointer to
a reference of that object, and then proceeds to rely on that pointer to
refer to that object even when the object is no longer guaranteed to exist
then this is bad code.

If this case is being used to attempt to demonstrate how C is unsafe but it
only manages to present code which is buggy and fundamentally broken then it
isn't possible to even consider if the code can be seen as unsafe. This
example is, by definition, an "erroneous program". It isn't possible to
debate the perceived safety of a programming language by trying to pin on
the programming language a set of problems which are a consequence of
failing to write valid code in it.


Rui Maciel

 

[August Karlstrom]

If a tool is used contrary to how it was
designed to be used and in ways which are considered to be dangerous and an
obvious source of problems then this isn't an issue of whether a specific
feature is safe or unsafe. The real issue is whether the programmer
actually knows what he is doing. If the programmer doesn't know what he is
doing then, no matter how "safe" that language is, the programmer will
always find ways to screw things up.

To me this is the typical macho programmer attitude. We all know that
every programmer makes mistakes every now and then. What sets a safe
programming language apart from an unsafe language is that a program
written in the former is not allowed to proceed executing once it enters
an ill-defined state. This prevents data corruption and makes the error
*much* easier to find.


August

 

[Kleuskes & Moos]

Le 21/09/11 18:26, Kenneth Brody a critic :
Nobody wants to do that. I told you already that this is not a magical
solution to all problems. It s just a BETTER solution under certain
circumstances that can give more meaningful error messages than

bus error
core dumped.

And, (embedded programmers should know) not all CPUs have a MMU that
will crash... Many will just overwrite some other process memory or
whatever

Yes. They also have watchdog-timers (and other assorted precautions) and
usually the program is in ((E)EP)ROM and cannot be overwritten. RAM state
is irrelevant once the state is undefined.

-------------------------------------------------------------------------------
_______________________________________
/ Your CHEEKS sit like twin NECTARINES \
\ above a MOUTH that knows no BOUNDS -- /
---------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Rui Maciel]

To me dangling pointers represent the very definition of unsafeness.
What is an unsafe language to you?

The example you provided represented poorly written code where a pointer
refers to an object after it's lifetime as ended. Understanding an object's
storage duration is very basic stuff. Therefore, this code goes against
extremely basic concepts which are clearly defined and therefore can only be
written by incompetent programmers. A programming language cannot be deemed
safe or unsafe due to mistakes made by incompetent programmers. If that was
the case then even the most basic scripting language could be accused of
being unsafe if a fool could inadvertently write a script which runs any
acceptable but obviously unwanted command, such as rm -rf /*, and this isn't
true.


Rui Maciel

 

[Ian Collins]

Le 21/09/11 18:26, Kenneth Brody a critic :

Nobody wants to do that. I told you already that this is not
a magical solution to all problems. It s just a BETTER solution
under certain circumstances that can give more meaningful
error messages than

bus error
core dumped.

And, (embedded programmers should know) not all CPUs have
a MMU that will crash... Many will just overwrite some
other process memory or whatever

Which is one of the many reasons why we develop and test our code in a
hosted environment.

 

[Rui Maciel]

The primary goal of the computer industry over the past 50 years has been
to make it impossible for programmers to make mistakes. I.e., to reduce
the art of programming down to the level of flipping burgers at McDonalds
(and at comparable pay).

They have almost succeeded. And will do any day now...

This isn't necessarily a bad goal, provided that those who invest their time
and energy in it try to reach it by developing their own tools. If, on the
other hand, they try to reach their goal by attempting to "dumb down" and
corrupt widely established and successful tools to the point their
usefulness can be put into question then we have a problem. It would be
like complaining that construction work can be unsafe for the general,
untrained public and then trying to make it safe by imposing rules such as
forcing all caterpillar trucks to be made out of spongy foam.

This "C is unsafe because I can write broken code which refers to non-
existing objects" issue, to me, fits this category.


Rui Maciel

 

[August Karlstrom]

The example you provided represented poorly written code where a pointer
refers to an object after it's lifetime as ended.

Indeed, but my main point was to illustrate that the address-of operator
can lead to a type of undefined behavior that a safe language would not
allow. As I mentioned in a recent post, by a safe language I mean a
language that (at least) prevent invalid memory accesses.

A programming language cannot be deemed
safe or unsafe due to mistakes made by incompetent programmers.

Of course not, the word "safe" rather refers to type safety and memory
safety.


August

 

[Keith Thompson]

The example you provided represented poorly written code where
a pointer refers to an object after it's lifetime as ended.
Understanding an object's storage duration is very basic stuff.
Therefore, this code goes against extremely basic concepts
which are clearly defined and therefore can only be written by
incompetent programmers. A programming language cannot be deemed
safe or unsafe due to mistakes made by incompetent programmers.
If that was the case then even the most basic scripting language
could be accused of being unsafe if a fool could inadvertently
write a script which runs any acceptable but obviously unwanted
command, such as rm -rf /*, and this isn't true.

You almost seem to be implying that only incompetent programmers
make mistakes. I think what you really mean is that only incompetent
programmes make *certain kinds* of mistakes -- but I think that's
unrealistic.

There are real advantages to languages that make even stupid mistakes
(like using a pointer outside its lifetime) either easy to detect,
or impossible to make in the first place. (And yes, there are also
real advantages to languages like C that give you enough rope to
shoot yourself in the foot, and depend on the programmer to get
things right.)

One example: pre-ANSI C didn't have prototypes, and so compilers
weren't able to diagnose function calls that pass the wrong number
of parameters. I remember running into that when I was first
learning C (coming from a Pascal background), and being horrified.
You could argue (with some justification) that I was incompetent for
writing an incorrect call, but the language design was also partly at
fault for not providing a mechanism to catch such errors. (And the
C committee apparently agreed, and added prototypes to the language.)

The safety of a language is not a simple binary attribute. But a
language (like ANSI C) that diagnoses function calls with the wrong
number of arguments is *safer* than a language (like pre-ANSI C)
that doesn't.

 

[August Karlstrom]

Could you describe the semantics of scope and and lifetimes of variables
in such a language or do you know of an actual language where the above
code would make sense?

[...]
sub func2 {
my $local2 = 43;
return \$local2;
} [...]
func2 declares a local variable and initializes it to 43, but it
returns a *reference* to it. The variable itself continues to exist
as long as the reference exists, even though the function in which
it was lexically declared has returned.

OK, strange, but then $local2 cannot be a usual local (lexical) variable
put on the usual call stack. There must be something else going on in
the background.


August

 

[Keith Thompson]

Could you describe the semantics of scope and and lifetimes of variables
in such a language or do you know of an actual language where the above
code would make sense?

[...]
sub func2 {
my $local2 = 43;
return \$local2;
} [...]
func2 declares a local variable and initializes it to 43, but it
returns a *reference* to it. The variable itself continues to exist
as long as the reference exists, even though the function in which
it was lexically declared has returned.

OK, strange, but then $local2 cannot be a usual local (lexical) variable
put on the usual call stack. There must be something else going on in
the background.

It's exactly the same kind of local variable as $local1 in my
other example. It behaves differently because there's an active
reference to it. That's how Perl works (and probably a lot of
other dynamic languages).

 

[August Karlstrom]

It's exactly the same kind of local variable as $local1 in my
other example. It behaves differently because there's an active
reference to it. That's how Perl works (and probably a lot of
other dynamic languages).

Perl usually works like no other language...


August

 

[James Kuyper]

Perl usually works like no other language...

Not in this case.

 

[James Kuyper]

On 09/21/2011 04:53 PM, August Karlstrom wrote:
....

Indeed, but my main point was to illustrate that the address-of operator
can lead to a type of undefined behavior that a safe language would not
allow.

But the problem you're trying to illustrate occurs only if the lifetime
of the object referred to ends before the reference to it created by
that operator is discarded. That can quite easily happen in C. However,
in languages with a quite different underlying architecture, the object
is guaranteed to continue existing as long as any reference to it
continues to exist.

 

[Malcolm McLean]

But the problem you're trying to illustrate occurs only if the lifetime
of the object referred to ends before the reference to it created by
that operator is discarded. That can quite easily happen in C. However,
in languages with a quite different underlying architecture, the object
is guaranteed to continue existing as long as any reference to it
continues to exist.

But it's impossible to guarantee that it means something.

I've a list of space invaders. When the player shoots one, the space
invader is deleted and removed from the list. I also have a list of
"spawning" space invaders. Due to a logical error, I don't update this
list when a space invader is zapped. Therefore a supposedly zapped
invader still spawns. In C, the pointer would point to a freed area of
memory, and the result would most likely be a crash. In a garbage
collection language, the invader would still be there, so the code
would most likely spawn a new invader in a blank area of screen. In
this case, the behaviour of the garbage collection code is probably
better, but both are erroneous.

 

[Keith Thompson]

yes that is the theory
but the pratice is i never find any such error in assembly until now

I was talking about C, not assembly.

[snip]

 

[Noob]

Try again. I'm a maintenance programmer. In other words: I fix the mess
that those hacks leave behind. In the caste system, which you seem so
proud of, I would be ranked lower than them, because I get to clean up
their mess.

So your whole rant falls flat on its face.

FYI, Navia is 30% troll, 20% spammer (peddling his warez).

IMO, he belongs in the bit bucket.

 

[James Kuyper]

But it's impossible to guarantee that it means something.

I've a list of space invaders. When the player shoots one, the space
invader is deleted and removed from the list. I also have a list of
"spawning" space invaders. Due to a logical error, I don't update this
list when a space invader is zapped. Therefore a supposedly zapped
invader still spawns. In C, the pointer would point to a freed area of
memory, and the result would most likely be a crash. In a garbage
collection language, the invader would still be there, so the code
would most likely spawn a new invader in a blank area of screen. In
this case, the behaviour of the garbage collection code is probably
better, but both are erroneous.

I don't claim that garbage collection solves all problems. I'm not
actually a fan of the technology - I prefer more deterministic control
of memory allocation. However, I understand the attractions of gc.

The best that any programming language can do is tell you that there's
internal inconsistencies in what you told the computer to do; none can
save you from the problems that occur when what you told it to do is
completely internally consistent, but different from what you wanted to
do. At least, not until mind-reading technology has been developed.