# nothing much

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

1. ### Phred PhungusGuest

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

2. ### SeebsGuest

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

3. ### Eric SosmanGuest

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
4. ### 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
5. ### Ben BacarisseGuest

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."

"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
6. ### Phred PhungusGuest

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

> document its choice ....

Implementations have to document something? How general is this
requirement?
--
fred

Phred Phungus, Mar 21, 2010
7. ### Phred PhungusGuest

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."
>
>
> "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
8. ### Eric SosmanGuest

On 3/21/2010 4:01 PM, Phred Phungus wrote:
>
> An interesting read. Beyond what Ben and Lawrence had to comment, I was
>
> > 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
9. ### SeebsGuest

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
10. ### Phred PhungusGuest

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
>>
>> > 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
11. ### SeebsGuest

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
12. ### Keith ThompsonGuest

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
>>>
>>> > 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
13. ### Nick KeighleyGuest

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

>
> >>>  > 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
14. ### Phred PhungusGuest

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
15. ### Phred PhungusGuest

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.

--
fred

Phred Phungus, Mar 28, 2010
16. ### Keith ThompsonGuest

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.

>

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
17. ### Phred PhungusGuest

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
18. ### Nick KeighleyGuest

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
19. ### Keith ThompsonGuest

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
20. ### Phred PhungusGuest

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