Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Rules for "undefined/implementation-defined behavior"

Reply
Thread Tools

Rules for "undefined/implementation-defined behavior"

 
 
Jon
Guest
Posts: n/a
 
      11-07-2010
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.


 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      11-08-2010
"Jon" <(E-Mail Removed)> wrote:
> 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?

--
Peter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
rules for Cisco PIX 525 firewall rules KAS Cisco 2 10-02-2005 07:12 PM
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Thunderbird email "rules"? joseph white Firefox 3 01-04-2005 08:49 PM
Having Problems with Message Rules and Dictionary Install. Reg Mouatt Firefox 7 10-04-2004 11:58 PM
Export/import rules? Jeff Boes Firefox 1 10-30-2003 10:53 PM



Advertisments