Proposal for Amendment to Section 6.5.3.2, Unary * Operator

[Shao Miller]

It's not the meaning of "undefined behavior" we're debating,
it's your questionable statement that a program *depends on*
undefined behavior.

Aha. Thanks for clarifying.

I think we all know what "undefined behavior" means. That's not the
problem.


That's not a guarantee.

It isn't? Ok, well we can agree to disagree on this one. I perceive
the guarantee from "behavior...for which this International Standard
imposes no requirements", but that could mean different things to
different people.

What "this program depends on undefined behavior" says to me is
"this program depends on the undefinedness of this behavior",
which is nonsensical.

What sorts of results would you get if you used this interpretation in
every other post where someone uses "undefined behavior"? Are you
suggesting that:

A: Look at my nice program.
B: Uh oh. Line 5 has undefined behaviour.
A: Then how in blazes does it compile and run and work as expected?
B: Uhh... Just by random chance.

is a meaningful conversation?

Yes, it's a meaningful conversation, though the last line is incomplete.
Random chance is certainly a possible explanation for the behavior of
the program (though not the only one).

How is it not meaningful?

In that it is incomplete. A is left with an incomplete understanding,
as you describe. Perhaps I misunderstood you: What did you mean by
"undefinedness"? Did you mean a predicate which is true when behaviour
falls into the C Standard definition for "undefined behavior" or did you
mean a predicate which is true when behaviour has no definition anywhere?

You articulated above that your problem with my statement was that it
looks like it claims that programs depend on the undefinedness of
certain behaviour. Since I couldn't make sense of the problem using the
aforementioned former predicate, I gave A's and B's conversation using
the latter. B is faced with explaining how the program can work despite
no definitions anywhere, so all B can offer is "random chance". If
instead B was using the Standard's definition, B could explain that the
behaviour might be defined by something external to the C Standard...
Precisely what I meant with the "problem" statement.

Well, it's not a definition, but it's certainly consistent with the
Standard's definition of "undefined behavior".

Then why not use that meaning for my "problem" statement? Why project
nonsense instead of agreement, however trivial?

With your bit above, I can type that your aim hit the bull's-eye and we
can agree. I meant that current C programs can and do depend on
specific behaviour that _is_ defined, though perhaps by something other
than the C Standard. Since you admit that that meaning is consistent
with the Standard definition, _that_ is the interpretation I'm thankful
for you to have for the "problem" statement.

Not really, no.

Ok, then I am mistaken.

If "undefined behavior" is so confusing, the Standard should call
it something else, like maybe "non-ISO". Imagine if I'd used "non-ISO
behaviour" instead of "undefined behaviour" in the original "problem"
statement. Could there have been any confusion, then?

I think you've completely missed the point. It's not about undefined
behavior, it's about the meaning of the phrase "depends on undefined
behavior".

Let me try to understand the problem again: Is it that my statement
could be interpreted to mean "depend on behaviour that is not defined at
all, anywhere"? Is it that my statement could be interpreted to mean
"depend on behaviour that oughtn't be defined by the C Standard"? Is it
that my statement could be interpreted to mean "depend on behaviour that
cannot be defined by the C Standard"? Is it that my statement could be
interpreted to mean "depend on behaviour that we cannot discuss since
it's outside of the C Standard"?

A program can depend on behavior that is defined by something other
than the C standard. Perhaps one could say that such a program
depends on a particular instance of undefined behavior (behavior
that is not defined by the C standard, but that is defined by
something else). I suppose that's what you mean by "depends on
undefined behavior", but it's not what that phrase says to me.

A particular instance, you say. Here's the "problem", again:

"Real C programs depend on the undefined behaviour of "dereferencing" a
null pointer constant cast to a complete object type under certain
circumstances."

There is a particular instance given _right_there_. A null pointer
constant cast to a complete object type yields undefined behaviour.
Real C programs depend on _that_ undefined behaviour, whatever it may be
and whoever might define it.

Here is some context, which is perhaps critically lacking:

A proposal for an amendment of C99's section 6.5.3.2 follows:
[snip unaffected passages.]
3 Except when the unary * operator and its operand are not evaluated,
the operand of the unary * operator shall not be a null pointer
constant expression, or such an expression cast to any pointer type.
Worse than pointless.

Are you suggesting that an implementation should be allowed to choose
to define the behaviour upon application of unary '*' to a null
pointer constant expression during translation?

Yes, of course. An implementation is always permitted to
provide its own definitions for behaviors the Standard leaves
undefined. In fact, it may be impossible for an implementation
to avoid doing so: If your program indulges in undefined behavior,
it will do *something* on any concrete implementation, and that
something, whatever it is, serves as a definition.

For example, many implementations define the behavior upon an
attempted dereference of NULL as "a SIGSEGV signal occurs."

Are you suggesting that an implementation should be allowed to choose
to define the behaviour upon application of unary '*' to a null
pointer constant expression during translation?

Many implementations currently allow dereferencing a null pointer (at
least for reading) to access the data at address 0. Although no C
object can be located there, the data might still be interesting. Other
implementations trap when a null pointer is dereferenced (at least for
writing) and some programs depend on that behaviour to produce a trap.
Why should such implementations be prohibited from allowing such
accesses in the most obvious manner? Particularly since dereferencing a
null pointer constant by accident is exceedingly unlikely.

That was precisely the reason that came to mind for me: deliberately
triggering an exception as a kind of "hardcoded breakpoint" to
trace through interesting areas of code without the need to set
large numbers of breakpoints manually in the debugger. There are
cleaner ways of doing this of course, such as assertions, but not
all platforms trigger a breakpoint on a failed assert(). It seems
to me that (in C at least) attempting to second guess what the
programmer may or may not want to do is generally a bad idea.

But that is actually a "yes" and not a "no."

You can see from this sampling that we have _already_ agreed that
programs depend on this particular case of undefined behaviour.
_And_yet_, when I offer to _discard_ a piece of _my_own_ proposal,
_even_that_ doesn't meet with agreement.

What is the _real_ reason for this?

If you will, please look at some of the history:

In "C Standard Regarding Null Pointer Dereferencing", I asked about a
few things and offered what I _perceived_ to be supporting definitions
from the C Standard. Nobody seemed too happy about it. But there was
at least some agreement that the wording in the Standard could use some
improvement. During this discussion, it became evident that _any_
agreement was _extremely_ difficult to achieve.

In an effort to measure what _could_ be agreed upon, I offered a
proposal in this "Proposal for Amendment to Section 6.5.3.2, Unary *
Operator" thread, including portions I _don't_ agree with. Surely
enough, _those_portions_ met with disagreement and valid, valuable
reasoning. Thank goodness.

Then I tried to shift into explicit agreement mode and discard a
mutually disagreeable piece of the proposal and BANG. Instant
disagreement. No luck, then. Apparently my use of "undefined
behaviour" is too confusing.

In "Undefined Behaviour Defined" I ask if "undefined behaviour" could be
too confusing a term in the Standard. BANG. Instant disagreement.

What is the meaning of this?

 

[Shao Miller]

Are you referring to the proposal to make dereferencing a null pointer
constant a constraint violation?
Yes.

How would that define the behaviour of
anything?

A constraint violation requires a diagnostic message, does it not? That
would be translation behaviour, to me. I get that impression from
'n1256.pdf', section 5.1.1.3, point 1.

The behaviour is undefined with or without the constraint.

Other than the diagnostic message during translation. The idea for
amended point #3 was that this construct result in a diagnostic message.
Multiple posters responded that programs use/depend on such constructs
for good reasons when they do, thus a diagnostic message is not
warranted. I fully agree.

The set of constructs with undefined behaviour doesn't change. The set
of allowed "undefined behaviours" (i.e. possible behaviours of a
construct with undefined behaviour) doesn't change either.

We needn't bother the programmer about their use of such constructs with
a diagnostic message during translation. They know what they're doing.

(Actually, the above is not quite true. Currently, the presence of an
expression that dereferences a null pointer constant doesn't
automatically make the program's behaviour undefined -- only an attempt
to evaluate that expression does. Your amendment would indeed break
some programs -- not ones that "depend on UB", but ones that rely on the
fact that an expression that dereferences a null pointer is not UB if
it's not evaluated.)

Please re-read it. Here it is:

"3 Except when the unary * operator and its operand are not evaluated,
the operand of the unary * operator shall not be a null pointer
constant expression, or such an expression cast to any pointer type."

Thank you, Mr. W. Lerch.

 

[Shao Miller]

"Real C programs depend on the undefined behaviour of "dereferencing" a
null pointer constant cast to a complete object type under certain
circumstances."

There is a particular instance given _right_there_. A null pointer
constant cast to a complete object type yields undefined behaviour. Real
C programs depend on _that_ undefined behaviour, whatever it may be and
whoever might define it.

Oops. I forgot "with unary '*' then applied to it". Sorry! Obviously
a null pointer constant cast to a complete object type does _not_ yield
undefined behaviour. I apologize in advance.

 

[Keith Thompson]

A particular instance, you say. Here's the "problem", again:

"Real C programs depend on the undefined behaviour of "dereferencing" a
null pointer constant cast to a complete object type under certain
circumstances."

There is a particular instance given _right_there_. A null pointer
constant cast to a complete object type yields undefined behaviour.
Real C programs depend on _that_ undefined behaviour, whatever it may be
and whoever might define it.

[...]

A statement that a program depends on that undefined behavior is
an incomplete statement. A program can depend on some *particular*
behavior. It cannot simply depend on undefined behavior.

If you don't get that, I doubt that there's any point in continuing
this discussion.

[...]

In "Undefined Behaviour Defined" I ask if "undefined behaviour" could be
too confusing a term in the Standard. BANG. Instant disagreement.

What is the meaning of this?

The meaning is that the term "undefined behavior" is not, for most
people, confusing. The C standard clearly defines it, it's an
appropriate term for the meaning, and it's not the cause of the
current confusion.

 

[Seebs]

The C standard clearly defines it, it's an
appropriate term for the meaning, and it's not the cause of the
current confusion.

But something closely tied to that definition resulted in him apparently
being wrong, so the definition is seriously broken and must be fixed.

-s

 

[Shao Miller]

But something closely tied to that definition resulted in him apparently
being wrong, so the definition is seriously broken and must be fixed.

A man once told me:

"When I used to walk back home from school, there was another student
who, each day, was typically a ways in front of me. He had a frequent
habit of turning his head and looking backwards as he walked. I did not
know the student and hardly ever saw him at school. As a result of
this, when I remember what he looked like, I encounter the strange
vision of somebody with his head on backwards."

Mr. P. Seebach:

If you perceive some flaws with my "inner state" (as you say) or with my
intentions during discussion about C, and if you perceive that talking
to me might be akin to talking to a "brick wall" (as you say), and if
you believe that such is a worth-while opinion to share in public and
with other people who I have a common interest with and whose discussion
(both listening to and speaking to) I strongly value, then would you be
kind enough to please use your mastery of my psyche to help me to
understand what action I need to take, in your expert opinion, which
could alleviate the requirement for your posts such as the above? What
do you want from me, Seebs? Seebs... Seebs? Are you there, Seebs?