Re: printf() question

Discussion in 'C Programming' started by Jun Woong, Jun 26, 2003.

  1. Jun Woong

    Jun Woong Guest

    (Dan Pop) wrote in message news:<bcn1ge$a2g$>...
    > In <> Keith Thompson <> writes:

    [...]
    > >
    > >In C99, falling off the end of main() without a return or exit() is
    > >equivalent to "return 0;". In C90, it isn't, and I've used
    > >implementations where it makes a difference.

    >
    > Nevertheless, C90 *explicitly* allows it. And, for the kind of programs
    > discussed here, it makes no difference.
    >


    Back to the original problem, the program is not s.c. if it contains
    undefined behavior even if its output doesn't depend on UB, is it?
    In fact, the program containing a return statement without an
    expression in its main() is not s.c. regardless of its output.

    If the main function executes a return that specifies no value,
    the termination status returned to the host environment is
    undefined.
    ~~~~~~~~~

    Is the reason that this doesn't count is because what is undefined is
    the termination status, not the behavior?


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jun 26, 2003
    #1
    1. Advertising

  2. Jun Woong

    Dan Pop Guest

    In <> (Jun Woong) writes:

    > (Dan Pop) wrote in message news:<bcn1ge$a2g$>...
    >> In <> Keith Thompson <> writes:

    >[...]
    >> >
    >> >In C99, falling off the end of main() without a return or exit() is
    >> >equivalent to "return 0;". In C90, it isn't, and I've used
    >> >implementations where it makes a difference.

    >>
    >> Nevertheless, C90 *explicitly* allows it. And, for the kind of programs
    >> discussed here, it makes no difference.
    >>

    >
    >Back to the original problem, the program is not s.c. if it contains
    >undefined behavior even if its output doesn't depend on UB, is it?
    >In fact, the program containing a return statement without an
    >expression in its main() is not s.c. regardless of its output.
    >
    > If the main function executes a return that specifies no value,
    > the termination status returned to the host environment is
    > undefined.
    > ~~~~~~~~~
    >Is the reason that this doesn't count is because what is undefined is
    >the termination status, not the behavior?


    Exactly. The program's behaviour is well defined and only the exit
    status is undefined. If the exit status is not part of the program's
    output, there is nothing preventing the program from being strictly
    conforming. And if the exit status is part of the program's output,
    there is no such thing as strictly conforming program, according to the
    current definition ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 27, 2003
    #2
    1. Advertising

  3. Jun Woong

    Jun Woong Guest


    > In <> (Jun Woong) writes:
    > > (Dan Pop) wrote in message news:...

    [...]
    > >Is the reason that this doesn't count is because what is undefined is
    > >the termination status, not the behavior?

    >
    > Exactly. The program's behaviour is well defined and only the exit
    > status is undefined.


    Then, it should be regarded as a defect of the superceded standard
    rather than regarded as it was *explicitly* allowed to use "return"
    without an expression in the main(), because the standard was/is
    intended to use only "undefined behavior." You can see this intent
    from a DR of C90:

    If the objects pointed to are not members of the same aggregate or
    union object, the result is undefined.
    ~~~~~~

    C90 explicitly said that the result (not the behavior) is undefined,
    which can imply that if the program doesn't use the resulting value
    it never invokes undefined behavior. But the committee said in the
    mentioned DR that "the result is undefined" should be understood as
    to mean "the behavior is undefined" like we can see the re-written
    wording in C99.

    For the exit status when the main() executes a return statement
    without an expression, it can be argued in either way, which I learned
    from the official documents written to draft C99; the behavior is
    undefined or the value for the exit status is unspecified. With the
    defective wording in the replaced standard, I think it's unfair to say
    that it's explicitly allowed.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jun 27, 2003
    #3
  4. Jun Woong

    Dan Pop Guest

    In <bdhop6$iur$> "Jun Woong" <> writes:


    >> In <> (Jun Woong) writes:
    >> > (Dan Pop) wrote in message news:...

    >[...]
    >> >Is the reason that this doesn't count is because what is undefined is
    >> >the termination status, not the behavior?

    >>
    >> Exactly. The program's behaviour is well defined and only the exit
    >> status is undefined.

    >
    >Then, it should be regarded as a defect of the superceded standard
    >rather than regarded as it was *explicitly* allowed to use "return"
    >without an expression in the main(), because the standard was/is
    >intended to use only "undefined behavior." You can see this intent
    >from a DR of C90:
    >
    > If the objects pointed to are not members of the same aggregate or
    > union object, the result is undefined.
    > ~~~~~~
    >
    >C90 explicitly said that the result (not the behavior) is undefined,
    >which can imply that if the program doesn't use the resulting value
    >it never invokes undefined behavior. But the committee said in the
    >mentioned DR that "the result is undefined" should be understood as
    >to mean "the behavior is undefined" like we can see the re-written
    >wording in C99.
    >
    >For the exit status when the main() executes a return statement
    >without an expression, it can be argued in either way, which I learned
    >from the official documents written to draft C99; the behavior is
    >undefined or the value for the exit status is unspecified. With the
    >defective wording in the replaced standard, I think it's unfair to say
    >that it's explicitly allowed.


    The issue was discussed in comp.std.c back when C89/C90 was *the* C
    standard and the consensus [*] was that such a program does NOT invoke
    undefined behaviour. Which makes sense, considering that the exit
    status is not considered as part of the program's output.

    ----------
    [*] Only Doug believes otherwise ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 30, 2003
    #4
  5. Jun Woong

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bdpb23$4il$...
    > In <bdhop6$iur$> "Jun Woong" <> writes:

    [...]
    > >
    > >For the exit status when the main() executes a return statement
    > >without an expression, it can be argued in either way, which I learned
    > >from the official documents written to draft C99; the behavior is
    > >undefined or the value for the exit status is unspecified. With the
    > >defective wording in the replaced standard, I think it's unfair to say
    > >that it's explicitly allowed.

    >
    > The issue was discussed in comp.std.c back when C89/C90 was *the* C
    > standard


    Could you give me a reference to it or any hint like key words in its
    subject to dig up the discussion?

    > and the consensus [*] was that such a program does NOT invoke
    > undefined behaviour.


    Debatably, as you said there was one member who thought otherwise and
    with the fact that there was a chance to conclude it invokes UB in the
    committee meetings for drafting C99. Of course, I think it's
    acceptable to say that the exit status is unspecified when main()
    executes a return statement without an expression considering the
    current wording of C99, but never agree with that it's *explicitly*
    allowed.

    > Which makes sense, considering that the exit
    > status is not considered as part of the program's output.


    This is to be treated as a defect, thus I think it's improper to be a
    criterion for interpreting other problems.

    >
    > ----------
    > [*] Only Doug believes otherwise ;-)
    >



    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 1, 2003
    #5
  6. Jun Woong

    Dan Pop Guest

    In <bdrgan$fdf$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bdpb23$4il$...
    >> In <bdhop6$iur$> "Jun Woong" <> writes:

    >[...]
    >> >
    >> >For the exit status when the main() executes a return statement
    >> >without an expression, it can be argued in either way, which I learned
    >> >from the official documents written to draft C99; the behavior is
    >> >undefined or the value for the exit status is unspecified. With the
    >> >defective wording in the replaced standard, I think it's unfair to say
    >> >that it's explicitly allowed.

    >>
    >> The issue was discussed in comp.std.c back when C89/C90 was *the* C
    >> standard

    >
    >Could you give me a reference to it or any hint like key words in its
    >subject to dig up the discussion?


    Sorry, it was too long ago. Before the C9x days.

    >> and the consensus [*] was that such a program does NOT invoke
    >> undefined behaviour.

    >
    >Debatably, as you said there was one member who thought otherwise and


    Yup, the same one member who can't figure out what

    long c[2][2];

    means, who can't recognise \? as a standard C escape sequence and who
    believes that there is something wrong with sizeof(char[2 * SIZE_MAX]).

    >with the fact that there was a chance to conclude it invokes UB in the
    >committee meetings for drafting C99. Of course, I think it's
    >acceptable to say that the exit status is unspecified when main()
    >executes a return statement without an expression


    What is the difference, in context, between an unspecified exit status
    and an undefined exit status?

    >considering the
    >current wording of C99, but never agree with that it's *explicitly*
    >allowed.


    Sorry, the statement

    If the main function executes a return that specifies no value,
    the termination status returned to the host environment is undefined.

    is *explicitly* allowing this. In its *absence*, it would be easy to
    argue a case of undefined behaviour, because a function defined as
    returning int doesn't return anything, but its return value is used by
    its caller. So, engage your brain and try to explain the actual purpose
    of this statement (considering that, *without* it, the behaviour would be
    undefined).

    >> Which makes sense, considering that the exit
    >> status is not considered as part of the program's output.

    >
    >This is to be treated as a defect, thus I think it's improper to be a
    >criterion for interpreting other problems.


    You're treating it as a defect. Big difference!

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jul 1, 2003
    #6
  7. Jun Woong

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bdrv2k$o3r$...
    > In <bdrgan$fdf$> "Jun Woong" <> writes:

    [...]
    > >
    > >Debatably, as you said there was one member who thought otherwise and

    >
    > Yup, the same one member who can't figure out what
    >
    > long c[2][2];
    >
    > means, who can't recognise \? as a standard C escape sequence and who
    > believes that there is something wrong with sizeof(char[2 * SIZE_MAX]).
    >


    I don't want to care about emotional criticism between you.

    > >with the fact that there was a chance to conclude it invokes UB in the
    > >committee meetings for drafting C99. Of course, I think it's
    > >acceptable to say that the exit status is unspecified when main()
    > >executes a return statement without an expression

    >
    > What is the difference, in context, between an unspecified exit status
    > and an undefined exit status?


    It affects conformance of programs.

    >
    > Sorry, the statement
    >
    > If the main function executes a return that specifies no value,
    > the termination status returned to the host environment is undefined.
    >
    > is *explicitly* allowing this.


    According to your logic, in C90, this was explicitly allowed too,
    which is completely opposite to the committee's intent:

    int *p = 0;
    p <= 0;

    > So, engage your brain and try to explain the actual purpose
    > of this statement (considering that, *without* it, the behaviour would be
    > undefined).


    It's not a problem that the standard says "undefined (behavior)"
    redundantly, like which we can see many instances in C90 and much more
    in C99 (in comparison with C90). And note that in C90 there was some
    useless requirements that should be removed.

    Whenever "undefined" appears in C90, my interpretation is the
    "behavior" is undefined, not anything else, which is supported by the
    DR to deal with the problem in the description for the relational
    operators.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 1, 2003
    #7
  8. Jun Woong

    Dan Pop Guest

    In <bds22f$3ik$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bdrv2k$o3r$...
    >> In <bdrgan$fdf$> "Jun Woong" <> writes:

    >[...]
    >> >
    >> >Debatably, as you said there was one member who thought otherwise and

    >>
    >> Yup, the same one member who can't figure out what
    >>
    >> long c[2][2];
    >>
    >> means, who can't recognise \? as a standard C escape sequence and who
    >> believes that there is something wrong with sizeof(char[2 * SIZE_MAX]).

    >
    >I don't want to care about emotional criticism between you.


    I can't see *any* emotional argument above.

    >> >with the fact that there was a chance to conclude it invokes UB in the
    >> >committee meetings for drafting C99. Of course, I think it's
    >> >acceptable to say that the exit status is unspecified when main()
    >> >executes a return statement without an expression

    >>
    >> What is the difference, in context, between an unspecified exit status
    >> and an undefined exit status?

    >
    >It affects conformance of programs.


    How?

    >> Sorry, the statement
    >>
    >> If the main function executes a return that specifies no value,
    >> the termination status returned to the host environment is undefined.
    >>
    >> is *explicitly* allowing this.

    >
    >According to your logic, in C90, this was explicitly allowed too,
    >which is completely opposite to the committee's intent:
    >
    > int *p = 0;
    > p <= 0;


    It's none of my fault that the standard is poorly worded and the
    commitee wrote "the result is undefined" when they meant "the behaviour
    is undefined", and it is downright idiotic to extrapolate from one
    instance of poor wording to one which is properly worded.

    >> So, engage your brain and try to explain the actual purpose
    >> of this statement (considering that, *without* it, the behaviour would be
    >> undefined).

    >
    >It's not a problem that the standard says "undefined (behavior)"
    >redundantly, like which we can see many instances in C90 and much more
    >in C99 (in comparison with C90). And note that in C90 there was some
    >useless requirements that should be removed.


    ??? You're not addressing my question! What is the purpose of this text,
    considering that the program's behaviour would have been undefined *in its
    absence*?

    >Whenever "undefined" appears in C90, my interpretation is the
    >"behavior" is undefined, not anything else, which is supported by the
    >DR to deal with the problem in the description for the relational
    >operators.


    Not in this case, unless you're severely English impaired. What part of
    "the termination status returned to the host environment is undefined" is
    too difficult for you to understand? Why put this text in the standard at
    all, if the intent was to make the program's behaviour undefined?

    And, anyway, the issue was settled in comp.std.c, back when it was an
    issue at all, so your personal interpretation is entirely irrelevant.
    I'm afraid it is a bit too late for DRs against C90, but you can try ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jul 1, 2003
    #8
  9. Jun Woong

    Dan Pop Guest

    In <bdsd0e$is4$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bds749$a65$...
    >> In <bds22f$3ik$> "Jun Woong" <> writes:

    >[...]
    >> >
    >> >I don't want to care about emotional criticism between you.

    >>
    >> I can't see *any* emotional argument above.

    >
    >Aha! That's the reason that people often say your rudeness - you have
    >no idea of what you're doing.


    Isn't that a rude remark? ;-)

    Anyway, I have always a perfect idea of what I'm doing, which is more than
    I can say about you. The text in question contained *exclusively* factual
    evidence, there was nothing emotional in it.

    >> >It affects conformance of programs.

    >>
    >> How?

    >
    >If the exit status doesn't count as an output, the unspecified exit
    >status doesn't make the program not s.c. while the mere invocation of
    >UB does.


    There is no invocation of UB, unless you can *prove* otherwise. Your
    personal interpretations of the standard are of no interest to me, when
    they are at odds with both common sense and the opinions of some reliable
    committee members.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jul 2, 2003
    #9
  10. Jun Woong

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bduelq$r2l$...
    > In <bdsd0e$is4$> "Jun Woong" <> writes:

    [...]
    > >
    > >Aha! That's the reason that people often say your rudeness - you have
    > >no idea of what you're doing.

    >
    > Isn't that a rude remark? ;-)


    No, it's just a try to enlighten you on what you're doing. Have you
    ever read Keith's advice posted in c.s.c before? I never think that
    some mistakes by a person made in other context does justify to
    completely ignore his opinion.

    [...]
    > >
    > >If the exit status doesn't count as an output, the unspecified exit
    > >status doesn't make the program not s.c. while the mere invocation of
    > >UB does.

    >
    > There is no invocation of UB, unless you can *prove* otherwise.


    This also applies to you, since the wording in question is actually
    defective, which means that it's ambiguous and opens possibility for
    two different interpretations.

    > Your
    > personal interpretations of the standard are of no interest to me, when
    > they are at odds with both common sense


    You always think that what you believe is in accordance with common
    sense even when numbers of people say that's not the intent or truth,
    which is explicitly self-assertive. I strongly recommend you to learn
    how to discuss on a technical subject.

    > and the opinions of some reliable
    > committee members.
    >


    The document I mentioned repeatedly is written by a reliable committee
    member too and I don't think that Doug is not a reliable member
    considering his work done through process of C99 I've seen. More
    importantly I believe him more than you.

    Regardless of what you're thinking, the way in which you said about
    the exit status of main() executing "return;" is not proper, which is
    what I claim consistently; you should have said in more negative
    tones.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 2, 2003
    #10
  11. Jun Woong

    Dan Pop Guest

    In <bduspm$qop$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bduelq$r2l$...
    >> In <bdsd0e$is4$> "Jun Woong" <> writes:

    >[...]
    >> >
    >> >Aha! That's the reason that people often say your rudeness - you have
    >> >no idea of what you're doing.

    >>
    >> Isn't that a rude remark? ;-)

    >
    >No, it's just a try to enlighten you on what you're doing.


    No need: I know perfectly well what I'm doing.

    >Have you
    >ever read Keith's advice posted in c.s.c before? I never think that
    >some mistakes by a person made in other context does justify to
    >completely ignore his opinion.


    When the person has made as many *elementar* mistakes in a relatively
    short period of time, his opinion can no longer be considered reliable.

    On more esoteric issues, it is not at all uncommon for other committee
    members to disagree with Doug. And since they don't have Doug's history
    of elementary goofs...

    >[...]
    >> >
    >> >If the exit status doesn't count as an output, the unspecified exit
    >> >status doesn't make the program not s.c. while the mere invocation of
    >> >UB does.

    >>
    >> There is no invocation of UB, unless you can *prove* otherwise.

    >
    >This also applies to you, since the wording in question is actually
    >defective, which means that it's ambiguous and opens possibility for
    >two different interpretations.


    Nope: the text in question is NOT defective and it doesn't contain the
    expression "undefined behaviour". Furthermore, its *absence* would imply
    undefined behaviour. Q.E.D.

    >> Your
    >> personal interpretations of the standard are of no interest to me, when
    >> they are at odds with both common sense

    >
    >You always think that what you believe is in accordance with common
    >sense even when numbers of people say that's not the intent or truth,


    Yes, it is not uncommon for the intent on the committee to be different
    from what a common sense-based interpretation of their text suggests.
    It is not uncommon for different committee members to interpret the
    standard in different ways, either. Is any of these my fault?

    >which is explicitly self-assertive. I strongly recommend you to learn
    >how to discuss on a technical subject.


    I know how to do it, thank you very much.

    Please drop these personal remarks when discussing a technical issue:
    I am not interested. If you continue, I can do the same, degrading the
    technical contents of the discussion even further. See some samples
    below.

    >> and the opinions of some reliable
    >> committee members.

    >
    >The document I mentioned repeatedly is written by a reliable committee
    >member too and I don't think that Doug is not a reliable member
    >considering his work done through process of C99 I've seen. More
    >importantly I believe him more than you.


    Believe whomever you want. At your risk. It is sheer stupidity to take
    Doug's opinion over that of other committee members. But if he's the
    *only* committee member whose opinion supports yours... ;-)

    >Regardless of what you're thinking, the way in which you said about
    >the exit status of main() executing "return;" is not proper, which is
    >what I claim consistently; you should have said in more negative
    >tones.


    I'm afraid this paragraph is too incoherent to allow any comments.
    Try to put your thoughts into better English and avoid long statements.

    The text in question serves exactly *one* purpose: to point out that a
    program that doesn't return anything from main does NOT invoke undefined
    behaviour and the *only* thing that is left undefined by the standard is
    the program's exit status. Why? Because in the absence of that text,
    *other* parts of the standard would render the program's behaviour
    undefined. But this kind of common sense-based reasoning doesn't seem to
    have much appeal for you...

    Anyway, you can still post the question in comp.std.c...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jul 2, 2003
    #11
  12. Jun Woong

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bdv382$g9r$...
    > In <bduspm$qop$> "Jun Woong" <> writes:

    [...]
    > >
    > >This also applies to you, since the wording in question is actually
    > >defective, which means that it's ambiguous and opens possibility for
    > >two different interpretations.

    >
    > Nope: the text in question is NOT defective and it doesn't contain the
    > expression "undefined behaviour".


    The description for the relational operators doesn't also contain it,
    does it?

    > Furthermore, its *absence* would imply
    > undefined behaviour. Q.E.D.


    Irrelevant. You don't understand my answer to your past question yet.
    The absence of the problematic description for the relational
    operators does also imply undefined behavior, but it exists there with
    the defective wording "the result is undefined" and the committee
    explicitly said that "undefined behavior" was intended.

    > >
    > >You always think that what you believe is in accordance with common
    > >sense even when numbers of people say that's not the intent or truth,

    >
    > Yes, it is not uncommon for the intent on the committee to be different
    > from what a common sense-based interpretation of their text suggests.


    The common sense-based interpretation of "undefined result" is
    different from the real intent, "undefine behavior" as showed in the
    DR. Why should the "undefined status" differ? Just because you believe
    so?

    > Please drop these personal remarks when discussing a technical issue:
    > I am not interested. If you continue, I can do the same, degrading the
    > technical contents of the discussion even further. See some samples
    > below.


    You didn't need to show the samples, since you've already showed it
    many times.

    > Because in the absence of that text,
    > *other* parts of the standard would render the program's behaviour
    > undefined.


    Is this an only evidence to support your argument? See above.

    My question: don't you agree with my position that the wording in
    question is defective? What you meant is that it's well written and
    wouldn't need a DR against it if assuming that we can still submit
    a DR to C90, isn't it?


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 2, 2003
    #12
  13. Jun Woong

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:be1421$elo$...
    > In <bdv66i$85u$> "Jun Woong" <> writes:


    >
    > It is downright idiotic to extrapolate from one badly written paragraph to
    > a correctly written paragraph, isn't it?
    >

    [...]
    >
    > Not until you explain *why* it is irrelevant. The text *explicitly*
    > REMOVES undefined behaviour, leaving *only* the exit status undefined.
    >
    > Therefore, the first example program in K&R2 is NOT a program invoking
    > undefined behaviour, but a strictly conforming program.
    >


    Repeated maintenance without any improvement.

    > >You don't understand my answer to your past question yet.
    > >The absence of the problematic description for the relational
    > >operators does also imply undefined behavior,

    >
    > There is no undefined behavior implied there by the actual text.
    > The committee wanted the behaviour to be undefined, but goofed when
    > writing it down.

    [...]
    > Have they ever said anything similar about the text under
    > discussion?


    Because of the DR, the committee left some possibility for the
    "undefined" something that can be treated as "undefined value" to be
    understood to mean "undefined behavior":

    The C Standard uses the term ``indeterminately valued'' not
    ``undefined value.''

    > >
    > >The common sense-based interpretation of "undefined result" is
    > >different from the real intent, "undefine behavior" as showed in the
    > >DR. Why should the "undefined status" differ? Just because you believe
    > >so?

    >
    > Just because you cannot extrapolate one DR to a piece of text that has
    > absolutely nothing to do with it.


    Nothing to do with it? It's just your personal opinion. From the
    document written by a committee member:

    and change the last sentence of subclause 5.1.2.2.3 [...]

    [The concept of undefined value is carefully avoided elsewhere.]

    >
    > Yes, it would have been better to use "unspecified" instead of "undefined"


    That's what I'd like to say and the reason that you should have
    answered in more negative tones in your previous posting. Note that I
    can agree with that the intent of the committee might be to put
    "unspecified value" in that context, but I never agree with your
    wording, "it's *explicitly* allowed."

    > since the standard doesn't say
    > anywhere that "undefined" can be used as shorthand for "undefined
    > behaviour" and, therefore, the definition of "undefined behaviour" CANNOT
    > be extented to "undefined", despite your desperate efforts of doing it,
    > based on *one* instance where the committee talked about "undefined value"
    > when it meant "undefined behaviour".


    See the above citations and please engage your brain this time.

    >
    > Then again, even if it's too late for a DR, you can still ask in c.s.c.
    >


    As you know, a discussion in c.s.c can't form an authoritative
    interpretation unless it's published as an official answer to a DR or
    a TC. I already agree with your position that the "unspecified value"
    is intended there considering the current wording of C99, but what I
    keep saying is that the wording itself is not written well with the
    evidences mentioned above.

    I don't want to waste any more time with this discussion that has no
    practical value, because it's not the first time that you use poorly-
    phrased wording in your answer. I just hope newbies here not to accept
    it as it's written.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 3, 2003
    #13
  14. Jun Woong

    Kevin Easton Guest

    Jun Woong <> wrote:
    [...]
    > That's what I'd like to say and the reason that you should have
    > answered in more negative tones in your previous posting. Note that I
    > can agree with that the intent of the committee might be to put
    > "unspecified value" in that context, but I never agree with your
    > wording, "it's *explicitly* allowed."


    Huh? You're saying that because the committee *could* release a DR
    changing the meaning of that section, it can't be interpreted as
    written? It seems to me that, on the contrary, it *is* explicitly
    allowed up to and until such a DR or TC is issued.

    - Kevin.
    Kevin Easton, Jul 4, 2003
    #14
  15. Jun Woong

    Jun Woong Guest

    "Kevin Easton" <> wrote in message news:newscache$uy1hhh$37a$...
    > Jun Woong <> wrote:
    > [...]
    > > That's what I'd like to say and the reason that you should have
    > > answered in more negative tones in your previous posting. Note that I
    > > can agree with that the intent of the committee might be to put
    > > "unspecified value" in that context, but I never agree with your
    > > wording, "it's *explicitly* allowed."

    >
    > Huh? You're saying that because the committee *could* release a DR
    > changing the meaning of that section, it can't be interpreted as
    > written? It seems to me that, on the contrary, it *is* explicitly
    > allowed


    Have you ever read all of the citations in my posting? Because there
    was a published DR which implied that it was the intent to interpret
    "undefined" something (similar to "undefined value") as to mean
    "undefined behavior," and because there was a committee document where
    a committee member mentioned the problem which the sentence in
    question had, what I meant is that it's more proper to say "as I know,
    the intent is to allow such a construct" rather than "it's explicitly
    allowed."

    > up to and until such a DR or TC is issued.
    >


    C90 was superseded, so a DR or TC against C90 can't be published
    any more.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 4, 2003
    #15
  16. Jun Woong

    Kevin Easton Guest

    Jun Woong <> wrote:
    >
    > "Kevin Easton" <> wrote in message news:newscache$efrhhh$gzc$...

    [...]
    >> In other words, whether or
    >> not it is explicitly allowed is something that can be derived from the
    >> text of the standard alone (as amended), and not from any non-normative

    > ~~~~~~~~~~~~~~~~~~~~~~~~~~
    >> comments, theories or other verbiage.

    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    > This is very foolish attitude to understand the standard, considering
    > that the standard itself is just means to express the committee's
    > intent; of course, I think that they should be more positive to revise
    > the normative text. This has already been discussed in c.s.c, I don't
    > want to repeat it. Moreover, according to your logic that's same as
    > Dan's, the following program is strictly conforming in C90 because the
    > normative text covered by the mentioned DR didn't be re-written and
    > the committee's answer given in DR is never normative by itself.
    >
    > int main(void)
    > {
    > int *p = 0;
    > p < 0; /* s.c. in C90, but not s.c. in C99? */
    > }


    Perhaps I don't know enough about the standardisation process, but I was
    under the impression that a DR answer was taken to amend the text of the
    standard?

    - Kevin.
    Kevin Easton, Jul 4, 2003
    #16
  17. Jun Woong

    Jun Woong Guest

    "Kevin Easton" <> wrote in message news:newscache$8taihh$5l8$...
    [...]
    >
    > Perhaps I don't know enough about the standardisation process, but I was
    > under the impression that a DR answer was taken to amend the text of the
    > standard?
    >


    Only some of them are taken to amend if the committee decides to
    publish them as a TC (technical corrigendum) for the standard. The
    rest of them just provide an explanation or the intended
    interpretation which forms the authoritative interpretation but are
    not taken as a normative text.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 4, 2003
    #17
  18. Jun Woong

    Kevin Easton Guest

    Jun Woong <> wrote:
    >
    > "Kevin Easton" <> wrote in message news:newscache$8taihh$5l8$...
    > [...]
    >>
    >> Perhaps I don't know enough about the standardisation process, but I was
    >> under the impression that a DR answer was taken to amend the text of the
    >> standard?
    >>

    >
    > Only some of them are taken to amend if the committee decides to
    > publish them as a TC (technical corrigendum) for the standard. The
    > rest of them just provide an explanation or the intended
    > interpretation which forms the authoritative interpretation but are
    > not taken as a normative text.


    So in the case you mentioned (relational operators), it should have been
    a TC, because the existing text wasn't just misleading, but actually
    meant something different to what was intended?

    - Kevin.
    Kevin Easton, Jul 5, 2003
    #18
  19. Jun Woong

    Jun Woong Guest

    "Kevin Easton" <> wrote in message news:newscache$zbzihh$5sg$...
    > Jun Woong <> wrote:
    > >

    [...]
    > >
    > > Only some of them are taken to amend if the committee decides to
    > > publish them as a TC (technical corrigendum) for the standard. The
    > > rest of them just provide an explanation or the intended
    > > interpretation which forms the authoritative interpretation but are
    > > not taken as a normative text.

    >
    > So in the case you mentioned (relational operators), it should have been
    > a TC,


    I think that many of DRs are worth being a TC (at least, in order not
    to make a situation like this), but the committee isn't positive to
    revise the normative text for a reason.

    > because the existing text wasn't just misleading, but actually
    > meant something different to what was intended?
    >


    I don't know what stopped them from publishing it as a TC for C90, but
    my understanding is that the committee tried to solve the DR by
    providing a general principle to interpret the standard, as you saw
    the sentence cited in one of my postings. Of course, I have no idea of
    whether or not they considered existence of "undefined status" when
    writing up the answer, but the resulting DR made the text in question
    unclear, which is my point and the reason that Clive, a committee
    member tried to rewrite it in handling some stuff for C99.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
    Jun Woong, Jul 5, 2003
    #19
    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. Edith Gross
    Replies:
    2
    Views:
    338
    =?iso-8859-1?Q?Juli=E1n?= Albo
    Nov 2, 2003
  2. ben
    Replies:
    4
    Views:
    614
    Martin Ambuhl
    Jun 26, 2004
  3. whatluo

    (void) printf vs printf

    whatluo, May 26, 2005, in forum: C Programming
    Replies:
    29
    Views:
    1,240
  4. azza

    printf affects following printf/s

    azza, Oct 17, 2010, in forum: C Programming
    Replies:
    0
    Views:
    431
  5. guru
    Replies:
    8
    Views:
    279
Loading...

Share This Page