Rules for "undefined/implementation-defined behavior"

Discussion in 'C Programming' started by Jon, Nov 7, 2010.

  1. Jon

    Jon Guest

    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. :)
     
    Jon, Nov 7, 2010
    #1
    1. Advertising

  2. "Jon" <> 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
     
    Peter Nilsson, Nov 8, 2010
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. thaneesh

    Code formatting rules in editor

    thaneesh, Jul 2, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    1,164
    thaneesh
    Jul 2, 2003
  2. Paul Johnson

    Business Rules & Referential Integrity

    Paul Johnson, Nov 20, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    563
    Paul Johnson
    Nov 20, 2004
  3. Bernt Fischer
    Replies:
    2
    Views:
    2,193
    Guogang
    Aug 28, 2003
  4. Jack
    Replies:
    7
    Views:
    734
    Kevin Spencer
    Jul 2, 2004
  5. Steffen Loringer

    Page access rules in web.config

    Steffen Loringer, Jun 23, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    3,774
    Pavan Apuroop
    Jun 23, 2005
Loading...

Share This Page