Testing if a pointer is valid

[Phil Carmody]

Looking at the original functions, they are just applying some
abstraction/hiding, so are doing exactly what macros are for.

Written as functions, they are not guaranteed to be inline. And some
overzealous maintainer might come along and decide the pointer
arguments need to be validated...

How would a macro be better defended against an overzealous
maintainter than an inline function.

Phil

 

[August Karlstrom]

I know of a language that has "pointers" - they call them pointers and use
the same "*" and "&" syntax that C uses - but these pointers are entirely safe
to use.

A language with an "address of" operator cannot be safe as is
illustrated by the following example:

T *x;

void f(void)
{
T y;

x = &y;
}

After calling f, x is invalid.


/August

 

[BartC]

How would a macro be better defended against an overzealous
maintainter than an inline function.

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.

 

[BartC]

A language with an "address of" operator cannot be safe as is illustrated
by the following example:

T *x;

void f(void)
{
T y;

x = &y;
}

After calling f, x is invalid.

It's possible to insist that only static objects (including functions) can
have & applied.

Where & is applied to a dynamic or transient object, then that can also be
protected, depending on how much the language is worried about invalid
pointers. C doesn't worry too much about it, and puts a lot of trust in the
programmer.

(And there are other ways of generating pointers than just using &.)

 

[Kleuskes & Moos]

Often you don't know how the app will be used.

In that case, you have little choice. Terminate ignobly and blame the
user of your lib.

For instance a
spreadsheet might be used for an undergraduate research project, or it
might hold details of cancer patients in a drugs trial. The requirements
are the same.

For a spreadsheet developer, that makes no difference.

Now lets say the program detects an invalid pointer. If it crashes out,
it destroys maybe six hours work by the undergraduate.

The graduate should have saved his work. Spreadsheets sport a "save"
option for that purpose.

That's a major
irritation. He won't use that package again and you've lost a customer.

If that were true, Microsoft would be bankrupt.

If you offer to save, of course you'll warn "this data may be
corrupted". One would hope that the cancer trial people have procedures.
But a harassed clerk has just spent half an hour entering new drug data.
She chooses the save option, looks at the data, it seems OK. 99% of the
time, she'll be right to accept it. Will the cancer trial people really
catch that one? Is it your responsibility, as spreadsheet programmer?

You just provided an excellent reason to let the damned thing just crash
instead of trying all kinds of clever little voodoo-tricks to catch a bad
pointer. Ample use of asserts in a design-by-contract setup and pay cuts
all around if one is triggered in the field? I'm all for it, but this is
getting ridiculous.

-------------------------------------------------------------------------------
________________________________________
/ I don't believe there really IS a GAS \
| SHORTAGE.. I think it's all just a BIG |
| HOAX on the part of the plastic sign |
\ salesmen -- to sell more numbers!! /
----------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Willem]

August Karlstrom wrote:
) On 2011-09-20 16:18, Kenny McCormack wrote:
)> I know of a language that has "pointers" - they call them pointers and use
)> the same "*" and "&" syntax that C uses - but these pointers are entirely safe
)> to use.
)
) A language with an "address of" operator cannot be safe as is
) illustrated by the following example:
)
) T *x;
)
) void f(void)
) {
) T y;
)
) x = &y;
) }
)
) After calling f, x is invalid.

Or not. Depending on the language. Which was the point. Duh.


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

 

[Willem]

BartC wrote:
) It's possible to insist that only static objects (including functions) can
) have & applied.
)
) Where & is applied to a dynamic or transient object, then that can also be
) protected, depending on how much the language is worried about invalid
) pointers. C doesn't worry too much about it, and puts a lot of trust in the
) programmer.

Or the language can simply make sure that the pointed-to object keeps
existing untill all pointers to it are gone. Which a lot of languages
do, actually.


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

 

[August Karlstrom]

August Karlstrom wrote:
) A language with an "address of" operator cannot be safe as is
) illustrated by the following example:
)
) T *x;
)
) void f(void)
) {
) T y;
)
) x =&y;
) }
)
) After calling f, x is invalid.

Or not. Depending on the language. Which was the point. Duh.

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?


August

 

[jacob navia]

Le 20/09/11 19:02, Willem a écrit :

BartC wrote:
) It's possible to insist that only static objects (including functions) can
) have& applied.
)
) Where& is applied to a dynamic or transient object, then that can also be
) protected, depending on how much the language is worried about invalid
) pointers. C doesn't worry too much about it, and puts a lot of trust in the
) programmer.

Or the language can simply make sure that the pointed-to object keeps
existing untill all pointers to it are gone. Which a lot of languages
do, actually.


SaSW, Willem

Well, C too does that.

Just download lcc-win and see. It has a built-in
garbage collector.

 

[Kenny McCormack]

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?

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. That's what I've been
saying all along. I don't see how posting C code is likely to tell us
anything about non-C languages (i.e., languages that aren't C).

Nitpickers note: Yes, I know there are some languages that are "almost C" -
probably close enough to C that your code would make sense to a
user/programmer of that "almost C" language, but that's obviously not the
point. And, as our friendly neighborhood regulars are so fond of pointing
out, C++ (for example) is completely different from C (as is C# and, for
that matter, anything else that isn't, in their tiny world view, C).
But I digress...

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 

[Willem]

August Karlstrom wrote:
) On 2011-09-20 19:00, Willem wrote:
)> August Karlstrom wrote:
)> Or not. Depending on the language. Which was the point. Duh.
)
) 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. A variable lives as long as there are pointers to it.

For languages, Any language that does GC will do. I read crossthread
there's even a C dialect that does it. C# probably, haven't really
done much in that. Perl for sure.


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

 

[Rui Maciel]

Any language in which it is possible for a pointer to be invalid but
which provides no way to test for validity is fundamentally flawed.

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.


Rui Maciel

 

[Rui Maciel]

Indeed. Testing a pointer by simple inspection can tell you whether it is
null or not. If it is null it is not valid. If not you simply can't tell.

A pointer being null or not tends to be a good enough sign that a pointer is
valid or not. If you put in practice a basic policy of adequately
initializing pointers and implementing a basic policy where the
responsibility of allocating and freeing memory is clearly established then
you only stumble on pointer problems if you fail to follow your own memory
allocation policy. If you happen to write code which makes use of
dynamically allocated memory while failing to adhere to such a basic
principle then you can only complain about how you are handling things, not
the tool you happen to be using at the time.


Rui Maciel

 

[Rui Maciel]

A language with an "address of" operator cannot be safe as is
illustrated by the following example:

T *x;

void f(void)
{
T y;

x = &y;
}

After calling f, x is invalid.

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.


Rui Maciel

 

[Rui Maciel]

Or the language can simply make sure that the pointed-to object keeps
existing untill all pointers to it are gone. Which a lot of languages
do, actually.

....or the programmer should be aware that objects do have a life time, and
it doesn't make sense to write code which refers to objects whose life time
has passed.


Rui Maciel

 

[Ike Naar]

Le 20/09/11 19:02, Willem a ?crit :

Well, C too does that.

Just download lcc-win and see. It has a built-in
garbage collector.

We're talking about a pointer to an automatic variable.
Does the lcc-win garbage collector handle those?
Or does it only handle pointers to allocated memory?

 

[jacob navia]

Le 20/09/11 22:30, Ike Naar a écrit :

We're talking about a pointer to an automatic variable.
Does the lcc-win garbage collector handle those?

Of course not, the code as shown will provoke a warning.
But an object will be kept until there are no pointers to it.

Or does it only handle pointers to allocated memory?

Yes, only gc malloced memory

 

[Willem]

Rui Maciel wrote:
) Willem wrote:
)
)> Or the language can simply make sure that the pointed-to object keeps
)> existing untill all pointers to it are gone. Which a lot of languages
)> do, actually.
)
) ...or the programmer should be aware that objects do have a life time, and
) it doesn't make sense to write code which refers to objects whose life time
) has passed.

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


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

 

[jacob navia]

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
of course not the first one) is their comptempt for the lower castes,
the lowly "programmers" that (of course) are bunch of lazy know
nothings.

There is a reason for that of course: Since they are so bad, those
programmers, a programmer MANAGER is needed, that will keep those
lazy bunch of hacks that write crap code under its supervision and all
will be MUCH better, specially with a language CONCEIVED for those
know-nothing hacking ignorants: JAVA.

I like C. Its motto is:

"Trust the programmer".

 

[August Karlstrom]

August Karlstrom wrote:
) 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. A variable lives as long as there are pointers to it.

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

For languages, Any language that does GC will do.

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


August