[union] Pointers to inherited structs are valid ?

[Philip Lantz]

I think there may be one more kind of pointer value, which is the
kind that caused this thread. It is a value that may appear in a
pointer object as a result of some prior undefined behavior. This
is of course outside the scope of the C standard--which is why it
correctly doesn't appear in your list--but it does occur in actual
implementations.

It behaves much like your type 1, but I'm not sure it's identical;
in particular, its behavior can't be described by referring to the
standard. Before reading this thread, I would not have ever
thought to call it a trap representation, but it is pretty
similar.

Let me see if I can help untangle the description you're giving.

[snip]

Of course, it should go without saying that the above assumes there
has been no previous undefined behavior.

Of course. So why did you write five paragraphs (reiterating stuff I
already know) when I specifically said there was prior undefined
behavior?

A kind of value along the lines
you describe -- we might call it "semi-defined" -- would be a
subset of the Type 1 class, not a separate class.

Wait, what? You think that the kind of value I describe, *specifically
caused by prior undefined behavior*, is a subset of one of your classes,
which specifically assume there has been no prior undefined behavior?

Whenever there has been
any previous undefined behavior, any assertion about how subsequent
actions will proceed might not hold up. There isn't any point in
talking about what might be true under such circumstances ...

Then why have you guys been talking about it for days?


The only reason to talk about it is that when someone is debugging and
observes unexpected behavior (behavior that was unexpected by the one
doing the debugging, of course), it sometimes helps to consider--in the
context of an actual implementation--how undefined behavior can lead to
the observed behavior, as a means of working backward to locate the
actual bug. My contributions to this thread have been a vain attempt to
point the discussion in this direction.

 

[Shao Miller]

Then why have you guys been talking about it for days?

The only reason to talk about it is that when someone is debugging and
observes unexpected behavior (behavior that was unexpected by the one
doing the debugging, of course), it sometimes helps to consider--in the
context of an actual implementation--how undefined behavior can lead to
the observed behavior, as a means of working backward to locate the
actual bug. My contributions to this thread have been a vain attempt to
point the discussion in this direction.

It's possible that discussion has continued this long:

- To debate particular points:

It's been argued whether or not arbitrary object representations for a
pointer type and for a given implementation can be considered to be trap
representations, for example.

- To establish a common understanding between people:

Fuzzy memories, news-reading context, misuse or imprecise use of
terminology, and even time of day can lead to confusion. Sometimes
people desire to be on the same page. If a discussant believes they
recognize that someone is misunderstanding their statements (which is
different than misunderstanding evidence for, or some claim of truth),
then that discussant might have an interest in attempting to clarify
their statements.

As an example of the latter: I don't think anyone's ever had any doubt
about the point for observations allowing someone to draw conclusions
about a possible cause for a particular behaviour. If that's right,
then that could explain why nobody has been particularly responsive to
your "vain attempt to point the discussion in this direction." Do you
believe that something you've contributed has been misunderstood?

Here is a repetition of something that's been stated several times
already: The first contribution that I remember reading from you seems
obviously to be the explanation for an observation about 0x0000000C that
had been mentioned. It was a real forehead-smacker, coupled with an
utterance of "Duh!" Continued discussion doesn't automatically imply
that your contribution was disputed, does it?

 

[Keith Thompson]

You're talking about undefined behaviour. I'm talking about
implementation-defined behaviour. This line cannot stand on its own...

[53 lines deleted]

I'm planning to follow up on this Real Soon Now; I just haven't had time
lately. Funny how being employed cuts into your free time.

 

[Shao Miller]

You're talking about undefined behaviour. I'm talking about
implementation-defined behaviour. This line cannot stand on its own...

[53 lines deleted]

I'm planning to follow up on this Real Soon Now; I just haven't had time
lately. Funny how being employed cuts into your free time.

It sure does! Best wishes for success in your new role. No sweat about
the discussion; week-ends sometimes work.

 

[Tim Rentsch]

I think there may be one more kind of pointer value, which is the
kind that caused this thread. It is a value that may appear in a
pointer object as a result of some prior undefined behavior. This
is of course outside the scope of the C standard--which is why it
correctly doesn't appear in your list--but it does occur in actual
implementations.

It behaves much like your type 1, but I'm not sure it's identical;
in particular, its behavior can't be described by referring to the
standard. Before reading this thread, I would not have ever
thought to call it a trap representation, but it is pretty
similar.

Let me see if I can help untangle the description you're giving.

[snip]

Of course, it should go without saying that the above assumes there
has been no previous undefined behavior.

Of course. So why did you write five paragraphs (reiterating stuff I
already know) when I specifically said there was prior undefined
behavior?

My previous posting (ie the response to Ben Bacarisse's post) was,
pretty clearly, only about how the Standard identifies different
kinds of behaviors, not anything more fine-grained. Your response
to that blurs the distinction between the two. I think it's
important to clarify which is which.

As for your question, well, I don't know what you know and what you
don't know, but even if I did, I wasn't writing just for you. What
I'm hoping to do is lay a clear foundation so that the less well
understood aspects can be discussed effectively.

Wait, what? You think that the kind of value I describe,
*specifically caused by prior undefined behavior*, is a subset
of one of your classes,

Yes. The various categories are each definitional, and together
they completely partition the space of pointer values.

which specifically assume there has been no prior undefined
behavior?

Here there is a mistake in logical inference. When I say "the
above assumes there has been no previous undefined behavior",
it means only that _some_ of the previous conclusions might
not hold if there has been previous undefined behavior, not
that they all might not. In any event, the descriptions of
the different classes are definitions, not conclusions.

To be fair I should add that these details may not have been
clear in my earlier writing.

Then why have you guys been talking about it for days?

I haven't. I only followed up to Ben Bacarisse's post because
I thought some people might find it helpful.

However, to clarify my earlier statement, there isn't any point
in talking about what might be true under such circumstances
_without some additional information_ that puts some sort of
bounds on (some cases of) undefined behavior. The key is to
identify which kinds of transgressions now have identifiable
semantics, and what the semantics are in such cases. But
this isn't easy.

The only reason to talk about it is that when someone is
debugging and observes unexpected behavior (behavior that was
unexpected by the one doing the debugging, of course), it
sometimes helps to consider -- in the context of an actual
implementation -- how undefined behavior can lead to the
observed behavior, as a means of working backward to locate the
actual bug. My contributions to this thread have been a vain
attempt to point the discussion in this direction.

In effect what's going on there -- ie, the considering -- is
imagining a more well-defined semantics for cases which are UB as
far as the Standard is concerned. It's important to know both
which cases have more well-defined semantics and what the new
semantics are. For example, on many machines, comparing pointers
using < always works for well-behaved pointer values, even if
they aren't in the same array, and even if one or both is a null
pointer. We might imagine a new semantics where < works with all
pointer values, and returns the right answer for cases the
Standard says are defined, and a "random" answer for the other
cases. So as long as the program doesn't depend in a drastic way
on the results of such pointer comparisons, they are harmless --
nothing bad will happen if there is a stray comparison here and
there (and for which both possible outcomes cause no further
problems).

But: tread cautiously! A similar example might reason that null
pointers have the value zero, and the memory around that location
is accessible, so dereferencing a null pointer is harmless if the
resulting value is ignored. OOPS! This is exactly the kind of
reasoning that led to the famous bug in the Linux kernel, because
gcc relied on the unlimited latitude of earlier undefined behavior.

So, bottom line... I agree that thinking about what might have
happened, undefined-behavior-wise, can be helpful in tracking down
a problem. But is also much harder than thinking about just what
well behaved programs will do, because of the myriad ways that
implementations can (and do!) manifest undefined behavior. And if
in spite of that someone wants to consider the consequences of
"semi-defined" behavior, they better be doggone sure they know
what the heck the implementation is doing (because there is a
pretty good chance it isn't doing what they think it's doing).