List of implementation dependent parts of C standard

Discussion in 'C Programming' started by embeddedc@hotmail.com, Dec 15, 2006.

  1. Guest

    Hi,

    Referring to C90, is there somewhere published a list of all parts of
    the standard where the behavior is not specified or implementation
    dependent?

    If not and I want to find all such parts I could search a pdf version
    of the standard for keywords such as "implementation dependent" to
    highlight the section. Can anybody suggest a complete list of such
    keywords to make sure I find all the relevant sections?

    Thank you.
    , Dec 15, 2006
    #1
    1. Advertising

  2. wrote:

    > Referring to C90, is there somewhere published a list of all parts of
    > the standard where the behavior is not specified or implementation
    > dependent?


    appendices F.1 and F.3 of X3.159

    > If not and I want to find all such parts I could search a pdf version
    > of the standard for keywords such as "implementation dependent" to
    > highlight the section. Can anybody suggest a complete list of such
    > keywords to make sure I find all the relevant sections?



    --
    Nick Keighley
    Nick Keighley, Dec 15, 2006
    #2
    1. Advertising

  3. Guest

    Nick Keighley wrote:

    > wrote:
    >
    > > Referring to C90, is there somewhere published a list of all parts of
    > > the standard where the behavior is not specified or implementation
    > > dependent?

    >
    > appendices F.1 and F.3 of X3.159
    >
    > > If not and I want to find all such parts I could search a pdf version
    > > of the standard for keywords such as "implementation dependent" to
    > > highlight the section. Can anybody suggest a complete list of such
    > > keywords to make sure I find all the relevant sections?

    >
    >
    > --
    > Nick Keighley



    Thank you for the information. It seems this document is not easy to
    find. Seems ANSI no longer supply the 89 version (not surprising),
    https://global.ihs.com can supply hard copy only, and I can get it in
    the book "The Annotated ANSI C Standard by Herbert
    Schildt". The last seems to be the best choice. Any other options?
    , Dec 15, 2006
    #3
  4. said:

    <snip>

    > Seems ANSI no longer supply the 89 version (not surprising),
    > https://global.ihs.com can supply hard copy only, and I can get it in
    > the book "The Annotated ANSI C Standard by Herbert
    > Schildt". The last seems to be the best choice.


    Provided you ignore the annotations, which are typically Schildtian, that's
    the cheapest and best way to get hold of the Standard, although the book
    does also contain at least one error in the text of the Standard itself.
    The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    Standard", http://www.lysator.liu.se/c/schildt.html

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
    Richard Heathfield, Dec 15, 2006
    #4
  5. Guest

    Richard Heathfield wrote:

    > said:
    >
    > <snip>
    >
    > > Seems ANSI no longer supply the 89 version (not surprising),
    > > https://global.ihs.com can supply hard copy only, and I can get it in
    > > the book "The Annotated ANSI C Standard by Herbert
    > > Schildt". The last seems to be the best choice.

    >
    > Provided you ignore the annotations, which are typically Schildtian, that's
    > the cheapest and best way to get hold of the Standard, although the book
    > does also contain at least one error in the text of the Standard itself.
    > The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    > Standard", http://www.lysator.liu.se/c/schildt.html
    >
    > --
    > Richard Heathfield
    > "Usenet is a strange place" - dmr 29/7/1999
    > http://www.cpax.org.uk
    > email: rjh at the above domain, - www.



    Just to check before I buy - the book contains the appendix F.1 and F.3?
    , Dec 15, 2006
    #5
  6. said:

    >
    > Richard Heathfield wrote:
    >
    >> said:
    >>
    >> <snip>
    >>
    >> > Seems ANSI no longer supply the 89 version (not surprising),
    >> > https://global.ihs.com can supply hard copy only, and I can get it in
    >> > the book "The Annotated ANSI C Standard by Herbert
    >> > Schildt". The last seems to be the best choice.

    >>
    >> Provided you ignore the annotations, which are typically Schildtian,
    >> that's the cheapest and best way to get hold of the Standard, although
    >> the book does also contain at least one error in the text of the Standard
    >> itself. The details are on Clive Feather's page, "The Annotated Annotated
    >> ANSI C Standard", http://www.lysator.liu.se/c/schildt.html

    >
    > Just to check before I buy - the book contains the appendix F.1 and F.3?


    Oh, good point. I have no idea. Sorry.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
    Richard Heathfield, Dec 15, 2006
    #6
  7. Random832 Guest

    2006-12-15 <>,
    Richard Heathfield wrote:
    > said:
    >
    > <snip>
    >
    >> Seems ANSI no longer supply the 89 version (not surprising),
    >> https://global.ihs.com can supply hard copy only, and I can get it in
    >> the book "The Annotated ANSI C Standard by Herbert
    >> Schildt". The last seems to be the best choice.

    >
    > Provided you ignore the annotations, which are typically Schildtian, that's
    > the cheapest and best way to get hold of the Standard, although the book
    > does also contain at least one error in the text of the Standard itself.
    > The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    > Standard", http://www.lysator.liu.se/c/schildt.html


    Eh. Some of what that page says is a bit off.

    } If main() is declared as void, I don't know of any compiler that will
    } return 0. Indeed, the standard forbids it to !

    The standard forbids no such thing. This is the most serious objection
    I have, the rest of this post is just filler.

    } if a signal can be raised within a library function (perhaps by an
    } external event such as the user pressing a BREAK key), then the signal
    } handler must not call that library function.

    Is this really true for all library functions?

    #include <signal.h>

    void abrt(int) {
    if(rand()%1) abort();
    else _Exit(EXIT_SUCCESS); }
    int main() {
    signal(SIGABRT,abrt)
    srand(time());
    abort(); }

    } There is no description of mktime and how it can be used to solve
    } problems like "what day is 100 days after December 25th 1993 ?"

    Is it really legal to add 100 days to a struct tm like this, or is it
    just a consequence of the way common implementations work?
    Random832, Dec 15, 2006
    #7
  8. Ben Pfaff Guest

    Random832 <> writes:

    > } There is no description of mktime and how it can be used to solve
    > } problems like "what day is 100 days after December 25th 1993 ?"
    >
    > Is it really legal to add 100 days to a struct tm like this, or is it
    > just a consequence of the way common implementations work?


    It's standard behavior:

    7.23.2.3 The mktime function

    Synopsis

    1 #include <time.h>
    time_t mktime(struct tm *timeptr);

    Description

    2 The mktime function converts the broken-down time, expressed as
    local time, in the structure pointed to by timeptr into a
    calendar time value with the same encoding as that of the
    values returned by the time function. The original values
    of the tm_wday and tm_yday components of the structure are
    ignored, and the original values of the other components are
    not restricted to the ranges indicated above.267) On
    successful completion, the values of the tm_wday and tm_yday
    components of the structure are set appropriately, and the
    other components are set to represent the specified calendar
    time, but with their values forced to the ranges indicated
    above; the final value of tm_mday is not set until tm_mon
    and tm_year are determined.

    --
    "Welcome to the wonderful world of undefined behavior, where the demons
    are nasal and the DeathStation users are nervous." --Daniel Fox
    Ben Pfaff, Dec 15, 2006
    #8
  9. Guest

    wrote:

    > Hi,
    >
    > Referring to C90, is there somewhere published a list of all parts of
    > the standard where the behavior is not specified or implementation
    > dependent?
    >
    > If not and I want to find all such parts I could search a pdf version
    > of the standard for keywords such as "implementation dependent" to
    > highlight the section. Can anybody suggest a complete list of such
    > keywords to make sure I find all the relevant sections?
    >
    > Thank you.



    On account that appendices F.1 and F.3 of X3.159 are not easy to come
    by - changing tact a bit I explain my problem.

    I want to document all parts of the standard that are not tightly
    defined. I can get this information from C99, but the compiler is
    likely neither 100% C99 nor 100% C89 compliant, therefore I also need
    the information for the C89 standard.

    Changes from C89 to C99 might have removed some of the implementation
    dependent parts making C99 a subset of C89. Therefore if I only
    document items relevant only C99 but the compiler is not completely C99
    compliant I may miss some things.

    If the parts of the standard that are implementation dependent are the
    same in C89 as C99, or the C89 is a subset of those in C99 then I have
    no problem - but how to prove?

    Thanks for the comments so far.
    , Dec 15, 2006
    #9
  10. Random832 <> writes:
    > 2006-12-15 <>,
    > Richard Heathfield wrote:
    >> said:
    >>
    >> <snip>
    >>
    >>> Seems ANSI no longer supply the 89 version (not surprising),
    >>> https://global.ihs.com can supply hard copy only, and I can get it in
    >>> the book "The Annotated ANSI C Standard by Herbert
    >>> Schildt". The last seems to be the best choice.

    >>
    >> Provided you ignore the annotations, which are typically Schildtian, that's
    >> the cheapest and best way to get hold of the Standard, although the book
    >> does also contain at least one error in the text of the Standard itself.
    >> The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    >> Standard", http://www.lysator.liu.se/c/schildt.html

    >
    > Eh. Some of what that page says is a bit off.
    >
    > } If main() is declared as void, I don't know of any compiler that will
    > } return 0. Indeed, the standard forbids it to !
    >
    > The standard forbids no such thing. This is the most serious objection
    > I have, the rest of this post is just filler.


    It depends on what you mean by "return 0". Certainly a program can
    return the equivalent of an exit status of 0 to its calling
    environment. But it's logically impossible for a void function to
    return 0, or any other value. If main is declared as
    "void main(void)", it cannot *as a function* return 0. I think that's
    what Clive meant; possibly he misunderstood what Schildt meant. (My
    copy of Schildt's book isn't handy, or I'd check.)

    [..]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 15, 2006
    #10
  11. Random832 Guest

    2006-12-15 <>,
    Keith Thompson wrote:
    > Random832 <> writes:
    >> 2006-12-15 <>,
    >> Richard Heathfield wrote:
    >>> said:
    >>>
    >>> <snip>
    >>>
    >>>> Seems ANSI no longer supply the 89 version (not surprising),
    >>>> https://global.ihs.com can supply hard copy only, and I can get it in
    >>>> the book "The Annotated ANSI C Standard by Herbert
    >>>> Schildt". The last seems to be the best choice.
    >>>
    >>> Provided you ignore the annotations, which are typically Schildtian, that's
    >>> the cheapest and best way to get hold of the Standard, although the book
    >>> does also contain at least one error in the text of the Standard itself.
    >>> The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    >>> Standard", http://www.lysator.liu.se/c/schildt.html

    >>
    >> Eh. Some of what that page says is a bit off.
    >>
    >> } If main() is declared as void, I don't know of any compiler that will
    >> } return 0. Indeed, the standard forbids it to !
    >>
    >> The standard forbids no such thing. This is the most serious objection
    >> I have, the rest of this post is just filler.

    >
    > It depends on what you mean by "return 0". Certainly a program can
    > return the equivalent of an exit status of 0 to its calling
    > environment. But it's logically impossible for a void function to
    > return 0, or any other value. If main is declared as
    > "void main(void)", it cannot *as a function* return 0. I think that's
    > what Clive meant; possibly he misunderstood what Schildt meant. (My
    > copy of Schildt's book isn't handy, or I'd check.)


    Implementations can make it do that, though, with appropriate warnings
    where necessary.

    An implementation which generated the same exact machine code for a void
    function, an integer function not returning a value, and an integer
    function returning 0 in all cases would, I believe, be 100% conformant.

    There's certainly absolutely nothing, in the narrowest sense, preventing
    any implementation from treating a main (or any other function, but
    that's neither here nor there) returning void, or not returning a value
    (either with return; or by reaching the closing brace pre-c99), as if it
    had returned 0, which I think was part of Schildt's point.

    Now, his point also seemed to be that it was _common_ to do so, which is
    incorrect and dangerous, so don't think for a minute that I'm endorsing
    Schildt. This is only the case anywhere in the real world in so far as
    the exit status is of no importance on some (few) implementations, and
    in so far as many implementations return values in a register such that
    there will be _something_ in that register even if nothing was placed
    there as part of a return statement, therefore not breaking code that
    doesn't care what the value was.

    But, as always: The standard forbids nothing in undefined cases.
    Random832, Dec 15, 2006
    #11
  12. Chris Torek Guest

    In article <>
    Random832 <> wrote:
    >But, as always: The standard forbids nothing in undefined cases.


    True enough.

    So, for a moment, consider the following translation unit:

    void foo(void) {
    return 0;
    }

    A C compiler must issue a diagnostic for this translation unit,
    because "return" with an expression is "forbidden" (to use the
    target word :) ) in a function whose return type is "void":

    6.6.6.4 The return statement

    Constraints

    [#1] A return statement with an expression shall not appear
    in a function whose return type is void. A return statement
    without an expression shall only appear in a function whose
    return type is void.

    (The C90 wording is slightly different, if I remember right, but
    still has a constraint against "return <expr>" in a void function
    like foo().)

    Now, if we change "foo" to "main", the C Standard allows undefined
    behavior because of "void main". As I recall, however, there was
    a DR on whether undefined behavior releases a compiler from the
    requirement to produce "at least one diagnostic" for a translation
    unit that contains constraint violations, to which the answer was
    "no, the compiler must still produce at least one diagnostic".

    Since 6.6.6.4 has the quoted constraints, the translation unit:

    void main(void) { return 0; }

    must thus also draw a diagnostic.

    I think it is not completely unreasonable to phrase "this translation
    unit must draw a diagnostic" as "the C standard forbids it", although
    the first phrase is better (because it is unambiguous -- the word
    "forbid" is not a Technical Standard-ese Term :) ).
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 15, 2006
    #12
  13. Random832 Guest

    2006-12-15 <>,
    Chris Torek wrote:

    > I think it is not completely unreasonable to phrase "this translation
    > unit must draw a diagnostic" as "the C standard forbids it", although
    > the first phrase is better (because it is unambiguous -- the word
    > "forbid" is not a Technical Standard-ese Term :) ).


    I didn't say the standard doesn't "forbid" the code, however you define
    it.

    I said that it does not forbid any behavior on the part of the compiler
    (except, of course, for silence, in the particular case you mentioned)
    Random832, Dec 16, 2006
    #13
  14. Chris Torek wrote:
    > In article <>
    > Random832 <> wrote:
    > >But, as always: The standard forbids nothing in undefined cases.

    >
    > True enough.
    >
    > So, for a moment, consider the following translation unit:
    >
    > void foo(void) {
    > return 0;
    > }
    >
    > A C compiler must issue a diagnostic for this translation unit,
    > because "return" with an expression is "forbidden" (to use the
    > target word :) ) in a function whose return type is "void":
    >
    > 6.6.6.4 The return statement
    >
    > Constraints
    >
    > [#1] A return statement with an expression shall not appear
    > in a function whose return type is void. A return statement
    > without an expression shall only appear in a function whose
    > return type is void.
    >
    > (The C90 wording is slightly different, if I remember right, but
    > still has a constraint against "return <expr>" in a void function
    > like foo().)
    >
    > Now, if we change "foo" to "main", the C Standard allows undefined
    > behavior because of "void main". As I recall, however, there was
    > a DR on whether undefined behavior releases a compiler from the
    > requirement to produce "at least one diagnostic" for a translation
    > unit that contains constraint violations, to which the answer was
    > "no, the compiler must still produce at least one diagnostic".


    DR17 Q3, DR102 and DR105. However, that does not necessarily apply
    unless a single part of the code is both undefined and a constraint
    violation simultaneously.
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=, Dec 16, 2006
    #14
  15. jaysome Guest

    On 15 Dec 2006 05:26:29 -0800, wrote:

    >
    >Richard Heathfield wrote:
    >
    >> said:
    >>
    >> <snip>
    >>
    >> > Seems ANSI no longer supply the 89 version (not surprising),
    >> > https://global.ihs.com can supply hard copy only, and I can get it in
    >> > the book "The Annotated ANSI C Standard by Herbert
    >> > Schildt". The last seems to be the best choice.

    >>
    >> Provided you ignore the annotations, which are typically Schildtian, that's
    >> the cheapest and best way to get hold of the Standard, although the book
    >> does also contain at least one error in the text of the Standard itself.
    >> The details are on Clive Feather's page, "The Annotated Annotated ANSI C
    >> Standard", http://www.lysator.liu.se/c/schildt.html
    >>
    >> --
    >> Richard Heathfield
    >> "Usenet is a strange place" - dmr 29/7/1999
    >> http://www.cpax.org.uk
    >> email: rjh at the above domain, - www.

    >
    >
    >Just to check before I buy - the book contains the appendix F.1 and F.3?


    The book contains Appendix G.1 and G.3, which are the equivalents to
    your F.1 and F.3. It also contains Appendix G.2 ("Undefined
    behavior"). Buy it, if you can.

    --
    jay
    jaysome, Dec 17, 2006
    #15
    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. Replies:
    3
    Views:
    582
    Keith Thompson
    Mar 31, 2007
  2. Replies:
    1
    Views:
    938
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Apr 12, 2007
  3. puzzlecracker
    Replies:
    1
    Views:
    508
    James Kanze
    Aug 7, 2008
  4. kizk
    Replies:
    0
    Views:
    560
Loading...

Share This Page