Testing if a pointer is valid

[Rui Maciel]

You are really stretching things here. The code you posted is C code,
right? How could it "make sense" in any other context?

To clarify: If we posit the existence of another language, in which
pointers are safe, then obviously that language isn't C.

The problem with this sort of assertion is that it is based on examples
which represent undefined behaviour, which, in this case, represent
"erroneous program constructs". 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.


Rui Maciel

 

[August Karlstrom]

You are really stretching things here. The code you posted is C code,
right? How could it "make sense" in any other context?

You mentioned a language that use the same syntax for pointer
indirection and address retrieval so I wrote a simple C-like example.
Don't get hung up on the syntax; we are talking about the semantics here.


August

 

[Rui Maciel]

So, either the language takes care of things, or the programmer
should be aware that the language does not take care of things.

Given the average programmer I come across, I prefer the first.

Or, to put it bluntly: in the Real World(tm), most programmers are
a bunch of hacks, who write crap code, so the invention of a language
that takes away responsibility from them is a Good Thing(tm).

In that case, those programmers should avoid posing a danger to themselves
and others by using tools which they don't know how to use. There are
plenty of tools in the real world which can easily do some real world harm,
but as the professionals who use them happen to be trained in their use then
they are as good as being full-proof.


Rui Maciel

 

[August Karlstrom]

If the language specification clearly states that y's lifetime ends when f()
finishes executing then referring to that object before or after f() is
executed represents bad code which is a sign of incompetence, not an
indication that the language is unsafe.

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


August

 

[James Kuyper]

How can a local variable live after the function has returned?

By not being local in the sense that you mean it. Imagine a language where

T *x;

void f(void)
{
T y;

x = &y;
}

Is treated as specifying the equivalent of C code like the following:

T *x;

void f(void)
{
T *py = gc_malloc(sizeof *py);
x = py;
}

where gc_malloc() is a allocator for a garbage-collected memory.

In that language, 'y' is treated as roughly the equivalent of the C
expression *py, and is local only in the sense that it's scope is
restricted to the body of f(). Under normal circumstances, it would be
garbage-collected shortly after exiting that scope. However, since the
pointer escapes the body of f(), the object 'y' designates will continue
to exist long after 'y' has gone out of scope.

But a garbage collector handles dynamically allocated objects, not local
variables.

That's not necessarily the case.

 

[August Karlstrom]

That's like saying that bicycles are fundamentally flawed because they don't
stop those who ride them from falling. Meanwhile, you ignore the fact that
those who adequately trained and practiced riding a bicycle tend to go on
with their lives without tasting pavement.

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.


August

 

[August Karlstrom]

By not being local in the sense that you mean it. Imagine a language where

T *x;

void f(void)
{
T y;

x =&y;
}

Is treated as specifying the equivalent of C code like the following:

T *x;

void f(void)
{
T *py = gc_malloc(sizeof *py);
x = py;
}

In my example the basic assumption was that y is *not* a pointer.
Otherwise your example makes sense.


August

 

[Keith Thompson]

Because he ought to know better.

An isolated function could conceivably be called from anywhere. A macro will
always be used in-line in a function where any 'inputs' might be expected to
be already verified or trusted.

Because macros are never defined in headers?

 

[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?

Yes, Perl:
====================
#!/usr/bin/perl

use strict;
use warnings;

sub func1 {
my $local1 = 42; # "my" creates a lexical variable
return $local1;
}

sub func2 {
my $local2 = 43;
return \$local2;
}

my $var1 = func1();
print '$var1 = ', $var1, "\n";

my $var2 = func2();
print '$var2 = ', $var2, " (a reference)\n";
print '$$var2 = ', $$var2, " (dereferencing \$var2)\n";
====================

Output:

$var1 = 42
$var2 = SCALAR(0x83f9f70) (a reference)
$$var2 = 43 (dereferencing $var2)

func1 simply declares a local variable, initializes it to 42, and
returns its value. The variable ceases to exist when func1 returns,
just as it would in C.

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.

C doesn't support this kind of thing. (Well, not directly; Perl
is implemented in C.)

 

[BartC]

Because macros are never defined in headers?

I don't understand why that would make a difference. I'm just making a point
that functions tend to be treated differently.

For example, a function might be analogous to a checkpoint on the border of
a country; you might well expect passport checks to be implemented. Whereas
a macro is more like a checkpoint within a country: anyone passing through
can be assumed to already have entitlement to be there, and therefore
passport checks are less likely to be needed.

 

[Willem]

jacob navia wrote:
) Le 20/09/11 22:35, Willem a ?crit :
)>
)> Given the average programmer I come across, I prefer the first.
)>
)> Or, to put it bluntly: in the Real World(tm), most programmers are
)> a bunch of hacks, who write crap code, so the invention of a language
)> that takes away responsibility from them is a Good Thing(tm).
)>
)>
)> SaSW, Willem
)
) What bothers me of those would be managers I have come across (you are

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.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Malcolm McLean]

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

This is even less safe

x = fooinanunsafelangage(y)
{
if(y = 'hahahaha')
return 'got you';
else
return 42;
}

Once you can't be sure what type you're going to be passed back,
testing gets very difficult. The connection with safe pointers is
that, to implement a safe pointer, many languages tag the pointer with
type information. That makes it very tempting to allow functions to
return arbitrary types, which leads to fooinanunsafelanguage.

 

[jacob navia]

Le 21/09/11 12:11, Malcolm McLean a écrit :

This is even less safe

x = fooinanunsafelangage(y)
{
if(y = 'hahahaha')
return 'got you';
else
return 42;
}

Once you can't be sure what type you're going to be passed back,
testing gets very difficult. The connection with safe pointers is
that, to implement a safe pointer, many languages tag the pointer with
type information. That makes it very tempting to allow functions to
return arbitrary types, which leads to fooinanunsafelanguage.

Yes, but there is even worst: making operations like "+" overloaded
so that "1" + "2" --> "12"

 

[Malcolm McLean]

Le 21/09/11 12:11, Malcolm McLean a crit :













Yes, but there is even worst: making operations like "+" overloaded
so that "1" + "2" --> "12"

Then they combine.

sequence = "1234567890123456789012345678901234567890123";
tail = sequence + foo(string);

tail equals "3", until string goes to "hahahaha", at which point tail
equals "1234567890123456789012345678901234567890123got you".

 

[James Kuyper]

In my example the basic assumption was that y is *not* a pointer.
Otherwise your example makes sense.

As far as this hypothetical language (which doesn't seem so hypothetical
now that I've seen other people cite similar real ones) is concerned,
'y' is not a pointer, it's an object. py represents a hidden
implementation detail which cannot be accessed directly, but only by use
of the construct '&y'.

 

[Kenny McCormack]

If the language specification clearly states that y's lifetime ends when f()
finishes executing then referring to that object before or after f() is
executed represents bad code which is a sign of incompetence, not an
indication that the language is unsafe.

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

I think most (sensible) people would agree that C is unsafe. So is
dynamite. Both are quite useful. Neither should be used by ordinary
citizens.

In this day and age, C is not a consumer product (neither is dynamite). C
once was (dynamite never was).

 

[Kenny McCormack]

The problem with this sort of assertion is that it is based on examples
which represent undefined behaviour, which, in this case, represent
"erroneous program constructs". 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.

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...

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[Kleuskes & Moos]

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).

Depends on what you call "the industry", the management surely would (if
they could).

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

I'm not quite that pessimistic. Non-trivial programs are
never trivially easy to write, whatever the language.

<quote src="Alan Perlis ACM-SIGPLAN '82, Epigrams in Programming">
When someone says "I want a programming language in which
I need only say what I wish done," give him a lollipop.
</quote>

-------------------------------------------------------------------------------
________________________________________
/ Is this the line for the latest \
| whimsical YUGOSLAVIAN drama which also |
| makes you want to CRY and reconsider |
\ the VIETNAM WAR? /
----------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Malcolm McLean]

I'm not quite that pessimistic. Non-trivial programs are
never trivially easy to write, whatever the language.

Depends what you mean by a trivial program.

For instance Mathematica stores everything as symbols. So if you write
sqrt(2) * sqrt(2) you always get exactly 2 as the answer. That's quite
hard to achieve in most languages, which store values as floating
point variables.

 

[Kleuskes & Moos]

Depends what you mean by a trivial program.

For instance Mathematica stores everything as symbols. So if you write
sqrt(2) * sqrt(2) you always get exactly 2 as the answer. That's quite
hard to achieve in most languages, which store values as floating point
variables.

Yes... I was thinking a bit bigger than that. Like writing Mathematica
or other projects of comparable size and complexity.

-------------------------------------------------------------------------------
______________________________________
/ Somewhere in Tenafly, New Jersey, a \
| chiropractor is viewing "Leave it to |
\ Beaver"! /
--------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------