Testing if a pointer is valid

[Phil Carmody]

As assertion is not as good as an argument. Do you have one?

Stop trying to be clever; do you not think I chose that word
for a reason? However, I should be flattered that you interpreted
what I wrote as it was intended, which is so rare nowadays, even
if you didn't work out my motivation for such wording.

However, one cannot have an argument *without* some assertions.
Call them axioms, call them postlates, call them whatever, but
they are not argued, they are asserted.

Phil

 

[Phil Carmody]

Phil Carmody wrote:
) Have you also had an appraisal where your manager looks at your
) last year's work, and informs you that you had a massively negative
) productivity, as measured by lines of code?

No, we don't do refactoring as it's too expensive, and the whole system
will be scrapped for the next-gen system five years ago.

I wasn't refactoring. I was bug-fixing. Removing shoddy code removed bugs.

Phil

 

[Phil Carmody]

Kick the testers in the balls. If that didn't show up in testing, someone
hasn't been doing their job.

On the planet where I live, either testers don't do their job, or
those who write test specs are incompetent. I'm on good terms with
a lot of our testers, I suspect it's the latter where I work. However,
fundamental functions not being tested is *incredibly* common.

Phil

 

[James Kuyper]

[Re: languages (not necessarily C or even C-like) with pointers]
....

Stop trying to be clever; do you not think I chose that word
for a reason? ...

Yes I considered that possibility - I just wanted to confirm that you
were making so weak a point. A language designer could with equal ease
assert to the contrary, and several apparently already have. I've never
made use of this feature of perl, and I've almost certainly never used
any of the other unspecified languages that have been referred to as
having this feature, so I've no idea how useful or dangerous it is.

Among other obvious possibilities, such a feature would slightly
simplify the writing of factory functions: instead of calling malloc()
to allocate the memory, they just declare a local object of the required
type, initialize it, and then return a pointer to it.

 

[James Kuyper]

Kick the testers in the balls. If that didn't show up in testing, someone
hasn't been doing their job.

You're assuming that the circumstances which cause this behavior are
easily reproduced. If it's hard to reproduce those circumstances, it's
correspondingly easy for even competent testers to fail to trigger it.
Perfectly competent testers are, like perfectly competent programmers,
easy to postulate, but very hard to hire.

 

[Kleuskes & Moos]

You're assuming that the circumstances which cause this behavior are
easily reproduced.

If the hypothetical doesn't specify that, there's no reason for me to
assume it.

If it's hard to reproduce those circumstances, it's
correspondingly easy for even competent testers to fail to trigger it.

If you're able to introduce hard-to-reproduce errors while setting up
menus, for which quite commonly used methods and API's exist, you're doing
_something_ wrong. You should probably kick yourself in the head instead.

Perfectly competent testers are, like perfectly competent programmers,
easy to postulate, but very hard to hire.

Yes. And hypothetical examples of things going wring are quite easy to come
up with and you can always bend them such that every objection can be easily
swept aside by adding another hypothetical restriction afterwards.

It's a _very_ cheap way of discussing things and generally, they do not add
much to the discussion. I see no reason to adjust my opinion.

-------------------------------------------------------------------------------
______________________________
< Am I in GRADUATE SCHOOL yet? >
------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Kleuskes & Moos]

On the planet where I live, either testers don't do their job, or those
who write test specs are incompetent. I'm on good terms with a lot of
our testers, I suspect it's the latter where I work. However,
fundamental functions not being tested is *incredibly* common.

You have a pretty fundamental problem, it seems.

-------------------------------------------------------------------------------
___________________________________
/ An Italian is COMBING his hair in \
\ suburban DES MOINES! /
-----------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Phil Carmody]

[Re: languages (not necessarily C or even C-like) with pointers]

This is a direct descendent of:
"""
Well, C too does that.
"""
Which looks like a claim about C and C alone.

...

Yes I considered that possibility - I just wanted to confirm that you
were making so weak a point. A language designer could with equal ease

.... do a lot of irrelevant things. The language designer in question
is Jacob, and he's perporting to implement C. I'm perfectly familiar
with perl and its references and have no issue that the concept makes
perfect sense in that language, but Jacob's claim was about how he was
doing 'C'.

Phil

 

[Phil Carmody]

You have a pretty fundamental problem, it seems.

Nope, I just work for Nokia. There's no debate that Nokia has
monumental problems.

Phil

 

[James Kuyper]

On 09/22/2011 03:07 PM, Phil Carmody wrote:

[Re: languages (not necessarily C or even C-like) with pointers]

This is a direct descendent of:
"""
Well, C too does that.
"""
Which looks like a claim about C and C alone.

That's a mis-reading of what jacob said, because "C" has a different
meaning in jacob's understand than it does in yours or mine.

Such a feature could be, depending upon how it's handled, a legitimate
extension to a fully conforming implementation of C, precisely because
the behavior is undefined, as far as the C standard is concerned. lcc's
extensions to C are, from jacob's point of view, just as much "C" as the
base language that they were extended from. His claims about "C" must
always be evaluated with that quirk of terminology in mind. What he
meant by that statement was really no different from what I would have
meant if I had said: "Well, lcc does that too." My comments were made
with that translation in mind.

... do a lot of irrelevant things. The language designer in question
is Jacob, and he's perporting to implement C.

I think jacob would acknowledge that what he's described is an extension
to C, and not anything guaranteed (or prohibited!) by the C standard itself.

 

[James Kuyper]

On 09/22/2011 03:07 PM, Phil Carmody wrote:

[Re: languages (not necessarily C or even C-like) with pointers]

This is a direct descendent of:
"""
Well, C too does that.
"""
Which looks like a claim about C and C alone.

That's a mis-reading of what jacob said, because "C" has a different
meaning in jacob's understand than it does in yours or mine.

Such a feature could be, depending upon how it's handled, a legitimate
extension to a fully conforming implementation of C, precisely because
the behavior is undefined, as far as the C standard is concerned. lcc's
extensions to C are, from jacob's point of view, just as much "C" as the
base language that they were extended from. His claims about "C" must
always be evaluated with that quirk of terminology in mind. What he
meant by that statement was really no different from what I would have
meant if I had said: "Well, lcc does that too." My comments were made
with that translation in mind.

... do a lot of irrelevant things. The language designer in question
is Jacob, and he's perporting to implement C.

I think jacob would acknowledge that what he's described is an extension
to C, and not anything guaranteed (or prohibited!) by the C standard itself.

 

[Kleuskes & Moos]

Nope, I just work for Nokia. There's no debate that Nokia has monumental
problems.

I would call that a pretty fundamental problem... I guess i'm just lucky
sticking to microcontrollers and DSP's and all kinds of funky platforms
like VxWorks.

My sincere condoleances. Good luck.

-------------------------------------------------------------------------------
______________________________________
< ... I have read the INSTRUCTIONS ... >
--------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[jacob navia]

Le 23/09/11 16:33, Phil Carmody a écrit :

... do a lot of irrelevant things. The language designer in question
is Jacob, and he's perporting to implement C. I'm perfectly familiar
with perl and its references and have no issue that the concept makes
perfect sense in that language, but Jacob's claim was about how he was
doing 'C'.

lcc-win has been shipping a garbage collector since 2004. It is a very
useful enhancement to the run time library, not to the language since
C doesn't change either its syntax or its semantics.

You allocate stuff with gc_malloc() and never free it. That is all
there is. I do not see why that is no longer 'C'.

 

[jacob navia]

Le 23/09/11 17:31, James Kuyper a écrit :

On 09/23/2011 05:28 AM, Phil Carmody wrote:
On 09/22/2011 03:07 PM, Phil Carmody wrote:

[Re: languages (not necessarily C or even C-like) with pointers]

This is a direct descendent of:
"""
Well, C too does that.
"""
Which looks like a claim about C and C alone.

That's a mis-reading of what jacob said, because "C" has a different
meaning in jacob's understand than it does in yours or mine.

Such a feature could be, depending upon how it's handled, a legitimate
extension to a fully conforming implementation of C, precisely because
the behavior is undefined, as far as the C standard is concerned.

I was speaking about the garbage collector, that lcc-win ships with its
runtime since 2005. I justdo not understand why you think that a
garbage collector "is not C" or whatever. I ship a statistics library
too, and with the same reasoning you could say that "It is not C"
because the standard doesn't mention statistics.

lcc's
extensions to C are, from jacob's point of view, just as much "C" as the
base language that they were extended from.

Yes, since a garbage collector doesn't change either the syntax or
the semantics of the language. What is going on on your mind?

Are you OK?

His claims about "C" must
always be evaluated with that quirk of terminology in mind. What he
meant by that statement was really no different from what I would have
meant if I had said: "Well, lcc does that too." My comments were made
with that translation in mind.

OK, you do not like me or lcc-win or both.

So what?

I think jacob would acknowledge that what he's described is an extension
to C, and not anything guaranteed (or prohibited!) by the C standard itself.

ANY library shipped with the compiler then is an "extension to C".

My statistics library is an "extension to C". The infinte precision
numbers are also "extensions".

This is ridiculous.

 

[Malcolm McLean]

You allocate stuff with gc_malloc() and never free it. That is all
there is. I do not see why that is no longer 'C'.

gc_malloc() can't be implemented in standard C, and requires intimate
knowledge of the architecture to sweep for orphaned memory blocks and
add them to the free list. That's enught o classify it as an extension
rather than simply as a new function. There's also the practical
reason that memory allocation is very fundamental, it changes the way
most programs are written.

 

[Ian Collins]

gc_malloc() can't be implemented in standard C, and requires intimate
knowledge of the architecture to sweep for orphaned memory blocks and
add them to the free list. That's enught o classify it as an extension
rather than simply as a new function. There's also the practical
reason that memory allocation is very fundamental, it changes the way
most programs are written.

I don't see why people get so hung up in garbage collection. The
compiler I mainly use has shipped with a collector since the 90s and it
is still a standard C compiler. If I want to use the collector, all I
have to do is link it with my standard C executable. Does the act of
linking a garbage collector somehow make my code non-standard?

 

[jacob navia]

Le 23/09/11 23:01, Ian Collins a écrit :

I don't see why people get so hung up in garbage collection. The
compiler I mainly use has shipped with a collector since the 90s and it
is still a standard C compiler. If I want to use the collector, all I
have to do is link it with my standard C executable. Does the act of
linking a garbage collector somehow make my code non-standard?

Well, that is gcc. Gcc can do whatever they want, the problem
is when lcc-win does the same

THEN

"It is not C"
"He is selling is Warez"

etc etc.

 

[James Kuyper]

Because gc_malloc() isn't a C standard library function. You could still
be working in a C environment, but gc_malloc() is not itself part of C.

However, the assertion was:

Le 20/09/11 19:02, Willem a ?crit : .... ....
Well, C too does that.

Since the object in question was automatic, this would involve a
radically bigger change to the language than simple adding the ability
to call gc_malloc().

 

[Ben Bacarisse]

I don't see why people get so hung up in garbage collection. The
compiler I mainly use has shipped with a collector since the 90s and
it is still a standard C compiler. If I want to use the collector,
all I have to do is link it with my standard C executable. Does the
act of linking a garbage collector somehow make my code non-standard?

Not "your code" but there are conforming C programs that will fail with
some garbage collected implementations. The details too horridly
contrived to matter (think %p and it's guarantees) so I mention it only
because this is c.l.c.

In reality, the problem is that one does not link against a GC allocator
just for fun. The reason is that the program allocates storage that is
not always freed and some people get uneasy about that. There are cases
where the code path is simply too complex to free everything reliably.
For example, in a simple interpreter for a high-level language I'd use
GC rather than try to determine every piece of storage's end of life.
There are other cases where it was simply that the programmer decided
not to bother. Whatever the reason, code that needs to be linked
against a collecting allocator is then tied to one and maybe that is
what makes people wary.

 

[James Kuyper]

I don't see why people get so hung up in garbage collection. The
compiler I mainly use has shipped with a collector since the 90s and it
is still a standard C compiler. If I want to use the collector, all I
have to do is link it with my standard C executable. Does the act of
linking a garbage collector somehow make my code non-standard?

"non-standard" is not a concept used by the C standard - it uses other
terms like "syntax error", "constraint violation", "unspecified
behavior", "undefined behavior", "conforming" and "strictly conforming"
when conveying such judgements.

Such linkage does not render your code non-conforming, it doesn't even
interfere with strict conformance. However, if you don't merely link to
the collector, but actually use it, that would interfere with strict
conformance. That's because the interface to the collector is not part
of any conforming implementation of the C standard library, and the
collector itself cannot be written in strictly conforming C. However,
very few programs are strictly conforming; possibly none that do
anything really useful.

The biggest conformance problem with using garbage collection is that
your code will not be portable to any implementation that doesn't
provide it, or which provides it by an incompatible mechanism. There's
nothing wrong with writing unportable code, so long as it is done
deliberately with a a proper understanding of the consequences.