C Standard Regarding Null Pointer Dereferencing

[John Kelly]

On 06 Aug 2010 22:55:50 GMT, Seebs <[email protected]>
wrote:

As to what you should do: Don't waste your time and ours with
petty resentments. Life is too short for that sort of thing.
Never again use the word "plonk". If you want to ignore someone
do it silently.

Good advice, but impossible to follow for an attention grabbing show-off
like Seebs.

 

[John Kelly]

You CAN defeat them online. If you are a literate person, you know
what constitutes a valid and well-written article, but you also know
that most people, especially software people, aren't very literate.
You know their judgements are crap. You know you've won.

But it's like winning a volleyball game. Maybe it was fun, but when
it's over, what have you actually won?

If life has made you bitter, there are better ways to deal with it.
Write some code and give it away. Volunteer with the Salvation Army.
Etc., etc.

 

[Seebs]

Anybody who can piss off Seebs is a friend of mine.

I think this should probably flatter me.

True fact, you heard it here first. John Kelly considers as friends:
* Sanford Wallace
* Various other junk faxers
* Telemarketers, especially scammers
* Bicycle thieves
* That lady at the supermarket hauling off and smacking her kid
* People who run folks off the highway while talking on cell phones

Esteemed company, to be sure.

-s

 

[Keith Thompson]

On Fri, 06 Aug 2010 10:53:24 -0700, Keith Thompson

[snip]

A large part of the reason we participate here is, frankly, to
explain to people why they're wrong.

We!!??? You certainly don't speak for me, and I dare say you
don't speak for many others.

[snip]

Ok, fair enough.

And we probably agree more than is implied by what I wrote above;
I was emphasizing one particular point because of the immediate
context.

(Incidentally, teaching doesn't apply just to newbies. I've learned
plenty of things here myself, not infrequently as a result of being
told I was wrong about something.)

 

[Seebs]

You said that S slighted you by saying that you claimed X. He
did not, either by intent, or by a reasonable reading of the
text. What happened is that you chose to perceive it as a slight
and produced a rationalization for perceiving it as a slight.

Actually, that one's not interesting to me; it's "invented" that
I said was a slight.

You said that he was plonked because he was wrong and that he
wouldn't learn. I submit "learn" means "accept my explanations
and authority".

Not in this case, no. However, he would have had to ACKNOWLEDGE
those explanations. I have no authority for him to accept; I'm
just some guy on the internet. However, someone who can go over
a week arguing with people about whether or not it is undefined
behavior to dereference a null pointer, and spends most of that time
refusing to even acknowledge that they have cited the standard and
provided arguments, is not willing to learn. Similarly, consider
his fixation on the *words* "claim" and "invented", even after
multiple participants explained about connotations and usage as being
the issues.

I don't know whether or not he *intends* to disregard peoples'
responses and advice, but in practice it seems he's not currently in
a place where he's able to genuinely accept (not in the sense of
believing, but merely truthfully seeing as what it is) input which
is contrary to his preconceived positions. Most people are like that
a fair bit of the time, but getting over it is probably the single
most important thing you can learn if you want to be an effective
engineer.

One of my friends has a good way of explaining it; if you don't
feel you could accurately state someone's position to their satisfaction,
you are perhaps not entirely ready to be arguing with them.

.... which is to say, the entirety of the above may be irrelevant,
as I may have missed your point. I believe that you are of the opinion
that I believe he should have accepted my positions on various issues
without demur; this is not my belief. I just got the impression that
he wasn't even really paying attention, in that he kept echoing back
things quite unlike what I said, or simply ignoring chunks of my
arguments, so far as I could tell. Coupled with his tendency to rudeness,
this led me to conclude that it would not be rewarding to spend time
trying to talk to him.

As to what you should do: Don't waste your time and ours with
petty resentments. Life is too short for that sort of thing.
Never again use the word "plonk". If you want to ignore someone
do it silently.

This is possibly good advice. However, I feel that there is some social
benefit to informing people of what behavior got them ignored -- this
can offer them a chance to correct that behavior, if they wish, and is
one of the ways people establish community norms that can help innoculate
a newsgroup against trolls. Help which, I submit, this newsgroup
desperately needs.

-s

 

[Seebs]

(Incidentally, teaching doesn't apply just to newbies. I've learned
plenty of things here myself, not infrequently as a result of being
told I was wrong about something.)

Yes. In general, I learn a lot more from finding out things that are
wrong than from finding out things that are right. Not sure why that is.

A couple months back, people finally convinced me that my view of
struct aliasing was wrong, and this has been very useful.

-s

 

[blmblm]

On 2010-08-06, Ben Bacarisse <[email protected]> wrote:

[ snip ]

For a vaguely C-related example:

Imagine that someone were to ask my opinion of a program, and I were to
respond "Well. It compiled."

Would you understand this to be a positive, neutral, or negative statement
about the program? (Hint: The answer is, so far as I can tell, fairly
unambiguous.)

In most contexts -- unambiguously positive.

In this group, though .... Well, I suppose "that's a good start"
is still positive, isn't it? even if followed by quibbles about
nonstandard or UB-invoking constructs?

(Attempt at humor.)

 

[Shao Miller]

... ... ...
However, someone who can go over
a week arguing with people about whether or not it is undefined
behavior to dereference a null pointer,
... ... ...

I'm still willing to argue about one particular detail, more than a week
later... "Sum total of possibilities"; but only insofar as C99.

Some _results_ (pun-ish[1]) (double-pun[2]) that I took away
(triple-pun[3]) from the valuable discussion were:

- At least some people believe that the wording regarding "...has been
assigned..." could be improved.

- If '*(char *)0' is not already a "void expression", then it is
required to have a value by the '(void)' cast in the expression:

(void)*(char *)0

(But this result was not entirely borne from the discussion.)

Moving on from such null pointers and onto application of unary '*' to
an expression with type 'void *':

- I'd _still_ argue that by the C99 draft with filename 'n1256.pdf',
there is _no_reason_ why "If...points to a function...if it points to an
object..." _must_ be taken as _requirements_ when "If...has
type...result has type..." clearly gives the expression a type 'void',
thus constituting a "void expression" (6.3.2.2,p1).

To me, that would seem to be an "implicit conversion". Seeing as how
there's no _other_ possible result that could conceivably be expected,
why should it _not_ constitute a void expression?

Furthermore, since it's the _result_ of '*' that would be the void
expression, the _operand_ would be evaluated, not an imaginary foe. The
same operand (a 'void *') is perfectly good for assignment and
comparison for equality and is evaluated in such instances.

- Perhaps fortunately for all of us, the C1X draft with filename
'n1494.pdf' now puts 'void' into the "object type" category, giving the
"If...points to..." is the "sum total of possibilities" argument greater
merit than for the C99 draft, in which incomplete types are another
category.

As per my note to Keith, I can hardly justify continued back-and-forth
regarding Seebs' (and others') reaction(s) to one or more of my posts in
this forum. One can only:
- Apologize
- Incorporate feedback into future behavioural decisions, for purposes
of respect for others' expectations
- Encourage tolerance where communications might lead to misunderstanding
- Explain that there have been no malicious intentions
- Describe my frame of reference in an attempt to foster an
understanding of why there were no malicious intentions
- Move on, and back to C

[1] The discussion included the meaning of "result", so that might be a pun
[2] "pun-ish" might be a pun, given certain other circumstances
[3] Taking away results yields an empty set of values, much as a 'void'
type represents

 

[Seebs]

In most contexts -- unambiguously positive.

I would regard it as pretty strongly negative. The only reason I'd be saying
that is to imply that it is surprising or new information, meaning I didn't
think the code was any good at all. I didn't say that it worked, or did what
it was supposed to do; in context, that strikes me as making the statement
strongly negative. Basically, it raises the question: Why didn't I say "it
worked" or "it looked solid" or something else that got to qualities beyond
some kind of absolute minimum level of acceptability? Even atrocious code
often compiles.

-s

 

[Shao Miller]

I would regard it as pretty strongly negative. The only reason I'd be saying
that is to imply that it is surprising or new information, meaning I didn't
think the code was any good at all. I didn't say that it worked, or did what
it was supposed to do; in context, that strikes me as making the statement
strongly negative. Basically, it raises the question: Why didn't I say "it
worked" or "it looked solid" or something else that got to qualities beyond
some kind of absolute minimum level of acceptability? Even atrocious code
often compiles.

What do Freudian slips[1], Rorschach inkblot tests[2] and the
Michelson-Morley experiment[3] have in common? ("Hardly justify", I said.)

[1] http://en.wikipedia.org/wiki/Freudian_slip
[2] http://en.wikipedia.org/wiki/Rorschach_test
[3] http://en.wikipedia.org/wiki/Michelson–Morley_experiment

 

[Keith Thompson]

Yeah .... Just following up to say that you didn't really need to
explain to me at greater length why continuing a public debate isn't
a good idea, though I don't suppose it (explaining more) hurts.
The problem isn't that I don't *know* what the sensible [*] thing
to do is ....

[...]

Ok. All I can do is offer my own opinion of what the sensible
thing to do is. For certain posters (spinoza1111 is definitely
one of them), I think the only sensible response is to completely
ignore them. If that means letting them have the last word, so
be it. If it means they write something utterly offensive or just
plain wrong and nobody ever refutes it, so be it. That's my advice,
whicn you are of course free to take or leave.

 

[John Kelly]

I can hardly justify ... Seebs

One can only:
- Apologize
- Incorporate feedback into future behavioural decisions, for purposes
of respect for others' expectations
- Encourage tolerance where communications might lead to misunderstanding
- Explain that there have been no malicious intentions
- Describe my frame of reference in an attempt to foster an
understanding of why there were no malicious intentions
- Move on, and back to C

Reasoning with show-off control freaks is futile. I avoid them.

 

[spinoza1111]

But it's like winning a volleyball game.  Maybe it was fun, but when
it's over, what have you actually won?

A volleyball game.

If life has made you bitter, there are better ways to deal with it.
Write some code and give it away.  Volunteer with the Salvation Army.

That's silly. People reconcile themselves to pretty twisted situations
with talk like that. "Be a slave". Life happens to be a fight to the
death for pure recognition, as in Hegel, and when they deny that it
is, they become twisted creeps like Seebach. With this talk of being
"bitter" you reveal that you're afraid of turning into your father and
overidentify with Mommy. Everybody was promised sugar tit for
conforming but I realized forty years ago that given environmental
degradation alone, we're not all going to be "winners".

What's wrong with standing up for what you think is right? I believe
Seebach to be incompetent, and over the past year or so, I have found
considerable evidence in his code, including the time he coded a one-
line strlen() and got it wrong. That by itself would not concern me at
all. The trouble is that he established a reputation by way of an
adolescent assault on a more qualified person, therefore it amuses me
to point out its failings, and it is the right thing to do.

More generally, it's the habit of the regulars here to fantasize that
"they are competent" but to define competence their own way, mostly
the following of half-understood "structured programming" that was
imposed on programmers in the 1970s to make sure they had "discipline"
and would criticise uncaring and incompetent managements.

In many computing environments, being able to speak and express
oneself clearly is dangerous. You might let the cat out of the bag
that a great deal of technology doesn't work properly and has been
jiggered to manufacture consent to the wealthy and their interests.
Techs on board Deepwater Horizon tried to point out that critical
alarm systems were at "blue screen of death" because they weren't
getting data from broken sensors but they were ignored or fired.

In such environments, "senior" people have memorized inference rules,
such as "complete sentences above a small upper bound of complexity
are trolling". They are through overwork and the concomitant substance
abuse of food, alcohol and drugs deeply uncultivated: for example, we
see here that their only referent for "poetry" is something from Star
Trek.

You've got people here who still are playing computer games and
clinging to Mommy past forty, like Seebach. The only realistic way for
me to proceed is to point this out.

 

[spinoza1111]

On Fri, 06 Aug 2010 10:53:24 -0700, Keith Thompson


[snip]

A large part of the reason we participate here is, frankly, to
explain to people why they're wrong.

We!!???  You certainly don't speak for me, and I dare say you
don't speak for many others.  In my view the value of a newsgroup
like this is to provide a place where skilled practioners can
discuss their art.  In other words it is about using C to write
programs, programs that are well written and well structured.

Kiki is being absurd, but beyond that, I don't think there is, any
more, a viable concept of what might constitute a "well written and
well-structured" program. My point is aesthetic. If too many clods
look at the Mona Lisa and discuss it, the Mona Lisa no longer exists
as an art object (no poetry after the Holocaust?)

A well structured program requires a well-structured society with
decency and fairness. But if medical insurance companies require their
employees to deny claims to make money, then medical insurance
software will be unstructured and incomprehensible at key points. If
an administration is voted in charged to bring some decency and
fairness into society, but that administration believes also in the
false idea that profits for some mean growth for all, then the "code"
of the new public programs will be a mess because it has a secret
agenda.

 

[spinoza1111]

'two_d_array[0]' thus has array type.  That means that for anything
other than 'sizeof' or '&', it becomes 'int *'.  That pointer points
to a valid object and so does incrementing that pointer by '20'.
Yes, I know that is your position.  There is no point in our repeating
the same things over and over.

But since I haven't pointed it out yet:

Type is not all there is to a pointer.
Agreed.



There is also a question of what
object the pointer points into.
Agreed.



 two_d_array[0] is an array[10],

Agreed.  Taking as valid our declaration, the sub-expression
'two_d_array[0]' is an expression with the type "array of int with ten
elements."  Another useful notation in addition to Peter's could be
'int[10]'.  Section 6.7.6 of the C standard draft with filename
'n1256.pdf'.

so when
it decays into a pointer, it decays into a pointer into that array of 10
objects.

Agreed...

It could possibly be confusing for a reader of the draft when
regarding "array type" versus "array object," if only "array" is
mentioned.  For example, 5.1.2.2.1,p2 "argv array", where "object" is
perhaps intended (there's no mention of 'argv' as a type).

Also, if only "an array object" is specified (as in 6.5.6,p8), it
might not be clear to a reader whether _any_ array object will do, or
if only _a_particular_ array object will do.

Unfortunately, 6.5.6,p8 results in a circular definition for "Array
subscripting", 6.5.2.1,p2, which defines the subscript operator in
terms including pointer arithmetic via the binary '+' operator, who
then defines pointer arithmetic in terms including the "difference of
the subscripts".  Oops.

For an object with "allocated" "storage duration" (6.2.4,p1), there
isn't even a "declared type" for an array object to work with, but
only the type of an lvalue used to access it (6.5,p6).  If we accept
"only _a_particular_ array object" above, it might be difficult to
accept any accesses to elements within an array object with allocated
storage, since:

The effective type is the type of the lvalue used to access the
object, in the case of an object with allocated storage.

 An implementation is welcome to detect attempts to move outside
the boundaries of that array.

Agreed.  Some bounds of arrays are known at translation-time and some
are not, also.

Furthermore, the decay Peter describes above looks like:

int[10] ---> int *

If an implementation attempts to keep track of the 'int *'-typed
result as "must point within an object with type 'int[10]'" instead of
discarding the bound, we can at least work around this by casting the
result to 'void *' or 'char *', then to 'int(*)[sizeof two_d_array /
sizeof two_d_array[0][0]]', then back to 'void *' or 'char *', then
back to an 'int *' like we started with.  The middle-measure should
discard any bound the implementation might have been attempting to
track.

To put it another way:

        int two_d_array[10][10];

        /* should be fine, this is guaranteed to be true */
        assert((two_d_array[0] + 10) == &(two_d_array[1][0]));
        two_d_array[1][0] = 1; /* valid */
        two_d_array[0][10] = 1; /* undefined behavior */

Well at least there's a work-around (detailed above) for concerns of
UB, here.

Comparison between pointers does not compare their boundaries.  (The assert
is safe because you are allowed to calculate the address of the object one
past the end of an array.)

I would suggest that implementations should attempt to work with the
knowledge of which locations are valid for which object types
('two_d_array' being declared for 100 contiguous 'int's), OR to drop
any tracked bound during the conversion of 'int[10]' to 'int *'.  Just
a suggestion.

In a four-dimensional array:

int fd[10][10][10][10];

'fd' (alone) is an expression with type 'int[10][10][10][10]', which
might become 'int(*)[10][10][10]'.
'fd[0]' (alone) is an expression with type 'int[10][10][10]', which
might become 'int(*)[10][10]'.
'fd[0][0]' (alone) is an expression with type 'int[10][10]', which
might become 'int(*)[10]'.
'fd[0][0][0]' (alone) is an expression with type 'int[10]', which
might become 'int *'.

Mr. Miller, are you aware that you are discussing this issue with
someone who's never taken a computer science class, never implemented
a compiler, and managed to get a one line strlen() wrong last year?

Peter Seebach made a false reputation by attacking a harmless and
mostly competent computer author circa 1995 to create the perception
that he knew his business. He volunteered to work on the standard to
pad his resume.

He speaks proudly of being ADD as if this deficiency gives him special
insight but after being found out on his one line strlen he said "I'm
not really good at this" or words to that effect.

As Harter has said, people come here to find real practitioners,
people who write C code for a living. But Seebach's job doesn't
involve much of that, since he finds bugs in software products. He
doesn't even fix them.

He targets people like Jacob Navia and myself (I'm author of a book on
compiler development for .Net, "Build Your Own .Net Language and
Compiler) when he senses real practitioners (I have thirty years in
the field) who refuse to conform, enabling cybernetic mobs. He also
makes a specialty of targeting people of non-American ethnicity or
with "weird names" since he's a racist.

 

[Shao Miller]

Mr. Miller, are you aware ... ... ...

Thank you for your concern and offering that I proceed with with caution
when determining who to engage in discussion.

... ... ...
As Harter has said, people come here to find real practitioners,
people who write C code for a living.

I agree that some people are hopeful for this; it's certainly why I
began posting here; an exchange of meaningful ideas with people with a
common interest in C and some experience, too.

... ... ...

I am sorry to read about personal conflict in Usenet, but will try my
best to avoid it.

Take care.

 

[John Kelly]

With this talk of being "bitter" you reveal that you're afraid of
turning into your father and overidentify with Mommy.

You're projecting.

 

[spinoza1111]

You're projecting.

No, I'm not. You pass on second-hand advice whose source is the
destruction of the ordinary person's ability to fight back because you
evince a certain attitude, call it "cool" in which it's not cool to
fight back.

This world-view is convenient to corporations.

I come in here to find Yet Another persecution of a "mark", now Shao
Miller, where people who know Seebach has a pattern of drawing
attention away from his incompetence by charging other people with
making errors (a form of transference or projection) might criticize
Seebach but don't have the decency to stand up for another human
being.

 

[spinoza1111]

On Fri, 06 Aug 2010 10:53:24 -0700, Keith Thompson

[snip]

A large part of the reason we participate here is, frankly, to
explain to people why they're wrong.

We!!???  You certainly don't speak for me, and I dare say you
don't speak for many others.

[snip]

Ok, fair enough.

And we probably agree more than is implied by what I wrote above;
I was emphasizing one particular point because of the immediate
context.

(Incidentally, teaching doesn't apply just to newbies.  I've learned
plenty of things here myself, not infrequently as a result of being
told I was wrong about something.)

One searches in vain for evidence of this, Kiki. You, Seebach and
Heathfield say that you admit when you're wrong, but only on narrow
technical points when you agree with the critic. You are deaf to
people who ask you to admit that it's wrong to use "troll" like Hitler
used "Jew".

 

[John Kelly]

No, I'm not. You pass on second-hand advice whose source is the
destruction of the ordinary person's ability to fight back because you
evince a certain attitude, call it "cool" in which it's not cool to
fight back.

I see the words but their meaning is inscrutable.

I come in here to find Yet Another persecution of a "mark", now Shao
Miller, where people who know Seebach has a pattern of drawing
attention away from his incompetence by charging other people with
making errors (a form of transference or projection) might criticize
Seebach but don't have the decency to stand up for another human
being.

OK Zorro.