nothing much

Discussion in 'C Programming' started by Phred Phungus, Mar 19, 2010.

  1. It's nice to see that russians are free enough to spread spam porn.

    I read elsewhere that signed integer division was undefined in C, with
    maybe a change having come in C99.

    Is that true?
    --
    fred
    Phred Phungus, Mar 19, 2010
    #1
    1. Advertising

  2. Phred Phungus

    Seebs Guest

    On 2010-03-19, Phred Phungus <> wrote:
    > I read elsewhere that signed integer division was undefined in C, with
    > maybe a change having come in C99.


    Did you?

    Could you indicate where this "elsewhere" was?

    The semantics of signed integer division have changed, arguably -- it used
    to be unspecified which of a couple of things happened in some cases, now
    it's more consistent. But this only applied when there were negative numbers
    involved -- signed positive numbers were always fine.

    And of course, division by zero is still undefined.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Mar 19, 2010
    #2
    1. Advertising

  3. Phred Phungus

    Eric Sosman Guest

    On 3/19/2010 1:49 AM, Phred Phungus wrote:
    > It's nice to see that russians are free enough to spread spam porn.
    >
    > I read elsewhere that signed integer division was undefined in C, with
    > maybe a change having come in C99.
    >
    > Is that true?


    No, with Yes.

    17 / 3 and 17 % 3 are and always have been well-defined,
    evaluating to 5 and 2, respectively.

    17 / -3 and 17 % -3 are also well-defined, and have been
    ever since the ANSI Standard was adopted. But in that Standard
    they could evaluate to -5 and -2 or to -6 and 1, the choice
    being left to the implementation. The implementation had to
    document its choice (and could not produce some third result),
    so again the division operation was well-defined, although
    (potentially) defined differently on different systems, just
    as CHAR_MIN is zero on some systems, negative on others.

    C99 *did* make a change: It removed the implementation's
    freedom of choice. The results must now be -5 and -2, and the
    pair -6 and 1 are forbidden. The operations are still defined.

    Integer division or mod by zero, signed or unsigned, has
    always been undefined. There's a rumor that the Committee is
    considering making INT_MIN % -1 (which must now be 0) either
    undefined or implementation-defined, I'm not sure which.

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 19, 2010
    #3
  4. Phred Phungus

    Guest

    Eric Sosman <> wrote:
    >
    > There's a rumor that the Committee is
    > considering making INT_MIN % -1 (which must now be 0) either
    > undefined or implementation-defined, I'm not sure which.


    It's undefined behavior if INT_MIN / -1 isn't representable, since most
    machines either throw an exception or produce an unspecified result
    (with an overflow indication) in that case. The Committee never
    intended to require a result of zero, although that isn't stated
    explicitly in the Standard.
    --
    Larry Jones

    All this was funny until she did the same thing to me. -- Calvin
    , Mar 19, 2010
    #4
  5. Eric Sosman <> writes:
    <snip>
    > Integer division or mod by zero, signed or unsigned, has
    > always been undefined. There's a rumor that the Committee is
    > considering making INT_MIN % -1 (which must now be 0) either
    > undefined or implementation-defined, I'm not sure which.


    Current draft wording makes it undefined on machines with INT_MIN <
    -INT_MAX. 6.5.5 p6 used to end:

    "If the quotient a/b is representable, the expression (a/b)*b + a%b
    shall equal a."

    and now (unofficially) reads:

    "If the quotient a/b is representable, the expression (a/b)*b + a%b
    shall equal a; otherwise, the behavior of both a/b and a%b is
    undefined."

    --
    Ben.
    Ben Bacarisse, Mar 19, 2010
    #5
  6. Eric Sosman wrote:
    > On 3/19/2010 1:49 AM, Phred Phungus wrote:
    >> It's nice to see that russians are free enough to spread spam porn.
    >>
    >> I read elsewhere that signed integer division was undefined in C, with
    >> maybe a change having come in C99.
    >>
    >> Is that true?

    >
    > No, with Yes.
    >
    > 17 / 3 and 17 % 3 are and always have been well-defined,
    > evaluating to 5 and 2, respectively.
    >
    > 17 / -3 and 17 % -3 are also well-defined, and have been
    > ever since the ANSI Standard was adopted. But in that Standard
    > they could evaluate to -5 and -2 or to -6 and 1, the choice
    > being left to the implementation. The implementation had to
    > document its choice (and could not produce some third result),
    > so again the division operation was well-defined, although
    > (potentially) defined differently on different systems, just
    > as CHAR_MIN is zero on some systems, negative on others.
    >
    > C99 *did* make a change: It removed the implementation's
    > freedom of choice. The results must now be -5 and -2, and the
    > pair -6 and 1 are forbidden. The operations are still defined.
    >
    > Integer division or mod by zero, signed or unsigned, has
    > always been undefined. There's a rumor that the Committee is
    > considering making INT_MIN % -1 (which must now be 0) either
    > undefined or implementation-defined, I'm not sure which.
    >


    An interesting read. Beyond what Ben and Lawrence had to comment, I was
    curious about this language:

    > The implementation had to
    > document its choice ....


    Implementations have to document something? How general is this
    requirement?
    --
    fred
    Phred Phungus, Mar 21, 2010
    #6
  7. Ben Bacarisse wrote:
    > Eric Sosman <> writes:
    > <snip>
    >> Integer division or mod by zero, signed or unsigned, has
    >> always been undefined. There's a rumor that the Committee is
    >> considering making INT_MIN % -1 (which must now be 0) either
    >> undefined or implementation-defined, I'm not sure which.

    >
    > Current draft wording makes it undefined on machines with INT_MIN <
    > -INT_MAX. 6.5.5 p6 used to end:
    >
    > "If the quotient a/b is representable, the expression (a/b)*b + a%b
    > shall equal a."
    >
    > and now (unofficially) reads:
    >
    > "If the quotient a/b is representable, the expression (a/b)*b + a%b
    > shall equal a; otherwise, the behavior of both a/b and a%b is
    > undefined."
    >


    That takes a little bit of head-scratching. I had to work a concrete
    example to see why the mathematics is sound.

    What a concise way to force a lot of behavior.
    --
    fred
    Phred Phungus, Mar 21, 2010
    #7
  8. Phred Phungus

    Eric Sosman Guest

    On 3/21/2010 4:01 PM, Phred Phungus wrote:
    >
    > An interesting read. Beyond what Ben and Lawrence had to comment, I was
    > curious about this language:
    >
    > > The implementation had to
    > > document its choice ....

    >
    > Implementations have to document something? How general is this
    > requirement?


    See Section 3.4.1.

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 21, 2010
    #8
  9. Phred Phungus

    Seebs Guest

    On 2010-03-21, Phred Phungus <> wrote:
    > Eric Sosman wrote:
    > > The implementation had to
    > > document its choice ....


    > Implementations have to document something? How general is this
    > requirement?


    Pretty much exactly as common as the words "implementation defined"
    in the standard, with one exception -- that being the description of
    the term "implementation defined".

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Mar 21, 2010
    #9
  10. Eric Sosman wrote:
    > On 3/21/2010 4:01 PM, Phred Phungus wrote:
    >>
    >> An interesting read. Beyond what Ben and Lawrence had to comment, I was
    >> curious about this language:
    >>
    >> > The implementation had to
    >> > document its choice ....

    >>
    >> Implementations have to document something? How general is this
    >> requirement?

    >
    > See Section 3.4.1.
    >

    3.4.1
    1 implementation-defined behavior
    unspecified behavior where each implementation documents how the
    choice is made. EXAMPLE An example of implementation-defined behavior
    is the propagation of the high-order bit when a signed integer is
    shifted right.

    So, if an implementation *doesn't* document how propagation occurs in
    the above example, is the behavior just unspecified or does it get
    bumped to undefined, as non-entities are?
    --
    fred
    Phred Phungus, Mar 23, 2010
    #10
  11. Phred Phungus

    Seebs Guest

    On 2010-03-23, Phred Phungus <> wrote:
    > 1 implementation-defined behavior
    > unspecified behavior where each implementation documents how the
    > choice is made. EXAMPLE An example of implementation-defined behavior
    > is the propagation of the high-order bit when a signed integer is
    > shifted right.


    > So, if an implementation *doesn't* document how propagation occurs in
    > the above example, is the behavior just unspecified or does it get
    > bumped to undefined, as non-entities are?


    Neither. In that case, the implementation is broken, and does not conform
    to the standard.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Mar 23, 2010
    #11
  12. Phred Phungus <> writes:
    > Eric Sosman wrote:
    >> On 3/21/2010 4:01 PM, Phred Phungus wrote:
    >>>
    >>> An interesting read. Beyond what Ben and Lawrence had to comment, I was
    >>> curious about this language:
    >>>
    >>> > The implementation had to
    >>> > document its choice ....
    >>>
    >>> Implementations have to document something? How general is this
    >>> requirement?

    >>
    >> See Section 3.4.1.
    >>

    > 3.4.1
    > 1 implementation-defined behavior
    > unspecified behavior where each implementation documents how the
    > choice is made. EXAMPLE An example of implementation-defined behavior
    > is the propagation of the high-order bit when a signed integer is
    > shifted right.
    >
    > So, if an implementation *doesn't* document how propagation occurs in
    > the above example, is the behavior just unspecified or does it get
    > bumped to undefined, as non-entities are?


    If an implementation doesn't document the behavior in a case
    where the standard requires it to do so, then the implementation
    is non-conforming, and the standard has nothing to say about it
    other than that it's non-conforming.

    In practice, of course, people aren't typically going to reject an
    implementation entirely just because some particular feature isn't
    properly documented. The point is that the standard doesn't specify
    a fallback position for implementations that fail to conform to it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 24, 2010
    #12
  13. On 24 Mar, 00:49, Keith Thompson <> wrote:
    > Phred Phungus <> writes:
    > > Eric Sosman wrote:
    > >> On 3/21/2010 4:01 PM, Phred Phungus wrote:



    > >>> An interesting read. Beyond what Ben and Lawrence had to comment, I was
    > >>> curious about this language:

    >
    > >>>  > The implementation had to document its choice ....

    >
    > >>> Implementations have to document something? How general is this
    > >>> requirement?


    I'm not sure what you mean. Section F.3 of the 1989 ANSI Standard (the
    ISO Standard numbers things slightly differently) lists the
    implementaion defined behaviours. There are about 14 sub-sections
    covering everything from identifier length to the behaviour of the
    register directive to various twisty corners of the library.


    > >>     See Section 3.4.1.

    >
    > >   3.4.1
    > > 1 implementation-defined behavior
    > >   unspecified behavior where each implementation documents how the
    > > choice is made.  EXAMPLE An example of implementation-defined behavior
    > > is the propagation of the high-order bit when a signed integer is
    > > shifted right.

    >
    > > So, if an implementation *doesn't* document how propagation occurs in
    > > the above example, is the behavior just unspecified or does it get
    > > bumped to undefined, as non-entities are?

    >
    > If an implementation doesn't document the behavior in a case
    > where the standard requires it to do so, then the implementation
    > is non-conforming, and the standard has nothing to say about it
    > other than that it's non-conforming.


    shoot. So when we asked our compiler supplier to send us the
    documentaion and he sent us the ANSI stanbdard instead we didn't have
    a conforming implementaion! On the other hand I still have a copy of
    the ANSI Standard...


    > In practice, of course, people aren't typically going to reject an
    > implementation entirely just because some particular feature isn't
    > properly documented.  The point is that the standard doesn't specify
    > a fallback position for implementations that fail to conform to it.
    Nick Keighley, Mar 24, 2010
    #13
  14. Nick Keighley wrote:
    > On 24 Mar, 00:49, Keith Thompson <> wrote:


    > I'm not sure what you mean. Section F.3 of the 1989 ANSI Standard (the
    > ISO Standard numbers things slightly differently) lists the
    > implementaion defined behaviours. There are about 14 sub-sections
    > covering everything from identifier length to the behaviour of the
    > register directive to various twisty corners of the library.
    >
    >
    >>>> See Section 3.4.1.
    >>> 3.4.1
    >>> 1 implementation-defined behavior
    >>> unspecified behavior where each implementation documents how the
    >>> choice is made. EXAMPLE An example of implementation-defined behavior
    >>> is the propagation of the high-order bit when a signed integer is
    >>> shifted right.
    >>> So, if an implementation *doesn't* document how propagation occurs in
    >>> the above example, is the behavior just unspecified or does it get
    >>> bumped to undefined, as non-entities are?

    >> If an implementation doesn't document the behavior in a case
    >> where the standard requires it to do so, then the implementation
    >> is non-conforming, and the standard has nothing to say about it
    >> other than that it's non-conforming.

    >
    > shoot. So when we asked our compiler supplier to send us the
    > documentaion and he sent us the ANSI stanbdard instead we didn't have
    > a conforming implementaion! On the other hand I still have a copy of
    > the ANSI Standard...
    >
    >
    >> In practice, of course, people aren't typically going to reject an
    >> implementation entirely just because some particular feature isn't
    >> properly documented. The point is that the standard doesn't specify
    >> a fallback position for implementations that fail to conform to it.

    >


    Ok, so is there a list of what a contemporary ISO implementation must
    document?
    --
    fred
    Phred Phungus, Mar 28, 2010
    #14
  15. Seebs wrote:
    > On 2010-03-23, Phred Phungus <> wrote:
    >> 1 implementation-defined behavior
    >> unspecified behavior where each implementation documents how the
    >> choice is made. EXAMPLE An example of implementation-defined behavior
    >> is the propagation of the high-order bit when a signed integer is
    >> shifted right.

    >
    >> So, if an implementation *doesn't* document how propagation occurs in
    >> the above example, is the behavior just unspecified or does it get
    >> bumped to undefined, as non-entities are?

    >
    > Neither. In that case, the implementation is broken, and does not conform
    > to the standard.


    Broken? How about imperfect?
    --
    fred
    Phred Phungus, Mar 28, 2010
    #15
  16. Phred Phungus <> writes:
    > Seebs wrote:
    >> On 2010-03-23, Phred Phungus <> wrote:
    >>> 1 implementation-defined behavior
    >>> unspecified behavior where each implementation documents how the
    >>> choice is made. EXAMPLE An example of implementation-defined
    >>> behavior is the propagation of the high-order bit when a signed
    >>> integer is shifted right.

    >>
    >>> So, if an implementation *doesn't* document how propagation occurs
    >>> in the above example, is the behavior just unspecified or does it
    >>> get bumped to undefined, as non-entities are?

    >>
    >> Neither. In that case, the implementation is broken, and does not conform
    >> to the standard.

    >
    > Broken? How about imperfect?


    The standard distinguishes between conforming and non-conforming
    implementations. It doesn't distinguish between slightly
    non-conforming (imperfect) and badly non-conforming (broken)
    implementations.

    Of course, you're free to make such a distinction if you like. Seebs
    apparently chooses not to do so.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 28, 2010
    #16
  17. Keith Thompson wrote:

    > The standard distinguishes between conforming and non-conforming
    > implementations. It doesn't distinguish between slightly
    > non-conforming (imperfect) and badly non-conforming (broken)
    > implementations.


    Ok. That was the lesser of the outstanding questions. The other goes
    to the contemporary ISO requirement. If it was annexed in '89, then
    there is a well-trodden path to what a conforming-implementation *must*
    document.

    Right?
    --
    fred
    Phred Phungus, Mar 28, 2010
    #17
  18. On 28 Mar, 05:00, Phred Phungus <> wrote:
    > Nick Keighley wrote:
    > > On 24 Mar, 00:49, Keith Thompson <> wrote:
    > > I'm not sure what you mean. Section F.3 of the 1989 ANSI Standard (the
    > > ISO Standard numbers things slightly differently) lists the
    > > implementaion defined behaviours. There are about 14 sub-sections
    > > covering everything from identifier length to the behaviour of the
    > > register directive to various twisty corners of the library.

    >
    > >>>>     See Section 3.4.1.
    > >>>   3.4.1
    > >>> 1 implementation-defined behavior
    > >>>   unspecified behavior where each implementation documents how the
    > >>> choice is made.  EXAMPLE An example of implementation-defined behavior
    > >>> is the propagation of the high-order bit when a signed integer is
    > >>> shifted right.
    > >>> So, if an implementation *doesn't* document how propagation occurs in
    > >>> the above example, is the behavior just unspecified or does it get
    > >>> bumped to undefined, as non-entities are?
    > >> If an implementation doesn't document the behavior in a case
    > >> where the standard requires it to do so, then the implementation
    > >> is non-conforming, and the standard has nothing to say about it
    > >> other than that it's non-conforming.

    >
    > > shoot. So when we asked our compiler supplier to send us the
    > > documentaion and he sent us the ANSI stanbdard instead we didn't have
    > > a conforming implementaion! On the other hand I still have a copy of
    > > the ANSI Standard...

    >
    > >> In practice, of course, people aren't typically going to reject an
    > >> implementation entirely just because some particular feature isn't
    > >> properly documented.  The point is that the standard doesn't specify
    > >> a fallback position for implementations that fail to conform to it.

    >
    > Ok, so is there a list of what a contemporary ISO implementation must
    > document?


    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

    that's C99 plus technical corrigenda (sp?). So that makes it C05 or
    something
    Nick Keighley, Mar 28, 2010
    #18
  19. Nick Keighley <> writes:
    > On 28 Mar, 05:00, Phred Phungus <> wrote:

    [...]
    >> Ok, so is there a list of what a contemporary ISO implementation must
    >> document?

    >
    > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
    >
    > that's C99 plus technical corrigenda (sp?). So that makes it C05 or
    > something


    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

    N1124 incorporates only the first two TCs; N1256 incorporates all
    three.

    Section 3 of annex J is an explicit list of the things a conforming
    implementation must document. The list is gathered from normative
    text in other sections of the standard. Annex J itself is
    informative, not normative; the list is provided for convenience.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 28, 2010
    #19
  20. Keith Thompson wrote:
    > Nick Keighley <> writes:
    >> On 28 Mar, 05:00, Phred Phungus <> wrote:

    > [...]
    >>> Ok, so is there a list of what a contemporary ISO implementation must
    >>> document?

    >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
    >>
    >> that's C99 plus technical corrigenda (sp?). So that makes it C05 or
    >> something

    >
    > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
    >
    > N1124 incorporates only the first two TCs; N1256 incorporates all
    > three.
    >
    > Section 3 of annex J is an explicit list of the things a conforming
    > implementation must document. The list is gathered from normative
    > text in other sections of the standard. Annex J itself is
    > informative, not normative; the list is provided for convenience.
    >


    I sure get a lot of mileage out of n1256.pdf.

    What does this mean:

    J.2 Undefined behavior
    1 The behavior is undefined in the following circumstances:
    — A ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a
    constraint is violated.
    (clause 4).

    Does gcc support the fortran keyword?
    --
    fred
    Phred Phungus, Mar 30, 2010
    #20
    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. Mark Kamoski

    setting to Nothing

    Mark Kamoski, Aug 7, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,076
    Robert Jacobson
    Aug 7, 2003
  2. cpp4ever
    Replies:
    3
    Views:
    362
    Francesco
    Sep 8, 2009
  3. Raymond Schanks
    Replies:
    0
    Views:
    504
    Raymond Schanks
    Apr 11, 2010
  4. Pete Mahoney
    Replies:
    1
    Views:
    214
    Ray at
    Dec 15, 2003
  5. Devin Jeanpierre
    Replies:
    2
    Views:
    431
    Devin Jeanpierre
    Feb 14, 2012
Loading...

Share This Page