Rules for "undefined/implementation-defined behavior"

[Jon]

Herein is "a proposal". While completely voluntary, of course, adopting
the concept in some or any way, or being even more actionable by doing
something more comprehensive than just changing your posting style, will
increase the signal-to-noise ratio in programming language discussions
and have other desireable effects. A side-effect is that it is another
vehicle to show-off your tecnical prowess (listen up "language
lawyers"!). While the desire is for broader scope adoption of the
concepts herein, this is a USENET newsgroup so this post is
newsgroup-centric, but it should be obvious that it has much wider
applicability. So, here it is...

*Simply* stating that something is "undefined behavior", is curt at best
and lame at worst, IMO. As such, I propose that there be "rules"
(world-wide, please... I wish!) associated with such statements. First,
one must make sure that he/she (hehe, *more* wishful thinking!) indeed
means "undefined behavior" and not "implementation-defined behavior".
That first one should cut down on the careless use of "undefined
behavior" considerably. If one uses the terms "implementation-defined
behavior", then one should state what common practice is in popular or
some/one implementation(s) is or make an effort to discover and state it
(at least until there is one or more nice places that facilitate such
discussions, e.g., FAQs, ISO standard update, databases, websites... and
one can then engage in discussion with phrases such as, "GCC's implements
C99 IDB 14 by doing...", where "IDB" stands for "implementation-defined
behavior" as classified/identified "somewhere").

For newsgroups, the FAQs should make it easy for group participants to
refer to common "mplementation-defined scenarios. This may be perhaps
nothing more than another section that is "Common Practices for
Implementation-defined Behavior" which enumerates and identifies the
common practices. More comprehensive treatment, such as what the *top*
compilers (VC, GCC...) do, can be done in the FAQs, or elsewhere by any
diligent and so inclined. The undefined/implementation-defined scenarios
will be easilly gleaned from newsgroup/forum discussions if participants
decide to adopt some form of the proposal given herein. (The
newsgroup-view is, of course, necessarily a micro-perspective of the
concept being brought forth herein).

OK, so how would one go about participating in the above you ask? It's
easy! If you state something is "undefined behavior" (and you are sure
that it is not "implementation-defined" behavior, state *why* it is
"undefined behavior". Is it because, perhaps and likely, that the
programming constructs being used are being used incorrectly? "Prove it!"
(and file it in the UB/IDB database). ;-) Is it because the ISO standard
does not address the scenario/construct usage pattern? The common
incorrect usage patterns/scenarios really need to be
classified/categorized/identified or something for ease of reference and
that too will be instructive in and of itself (see UB/IDB database
reference just preceding, or a simple listing would be a great start),
and if you are so inclined and have such desire, go for it!

Anyway, you get the concept by now I'm sure. So there it is.

 

[Peter Nilsson]

Herein is "a proposal". ...

I'm not sure I see any positive benefit to your proposal.
Certainly not for the effort you're asking _other people_
to go to for the benefit of people who mostly don't care
in the first place.

*Simply* stating that something is "undefined behavior",
is curt at best and lame at worst, IMO.

It's often 100% correct and needs no further explanation,
especially if there's a reference to the standard.

As such, I propose that there be "rules"
(world-wide, please... I wish!) associated with such
statements. First, one must make sure that he/she (hehe,
*more* wishful thinking!) indeed means "undefined behavior"
and not "implementation-defined behavior".

My experience is that the small percentage of people who know
the terms, already know the difference.

That first one should cut down on the careless use of
"undefined behavior" considerably.

I don't see a lot of careless use. I see a lot of indifferent
and naive readers though.

If one uses the terms "implementation-defined
behavior", then one should state what common practice is
in popular or some/one implementation(s) is or make an effort
to discover and state it

Why? If people only give a rats about what happens on platform X,
they can hop on one of the numerous platform X forums that don't
give a rats about maximally portable programming.

(at least until there is one or more nice places that
facilitate such discussions, e.g., FAQs, ISO standard update,
databases, websites... and one can then engage in discussion
with phrases such as, "GCC's implements C99 IDB 14 by doing...",
where "IDB" stands for "implementation-defined
behavior" as classified/identified "somewhere").

Um, implementation-defined means precisely that the implementation
is supposed to document the choice. So it comes down to RTFM. I
don't see a benefit to listing common behaviour. Either people
are interested in maximal portability, or they're not.

... so how would one go about participating in the above
you ask?

You haven't answered why one should do this.

It's easy! If you state something is "undefined behavior"
(and you are sure that it is not "implementation-defined"
behavior, state *why* it is "undefined behavior".

A simple reference to the standard should do.

Is it because, perhaps and likely, that the
programming constructs being used are being used
incorrectly? "Prove it!"

If the reference is a constraint violation, then QED.

(and file it in the UB/IDB database). ;-)

Are you aware of Appendix J (Portability issues?)

Are you aware of the Rationale?