Velocity Reviews > nothing much

# nothing much

Phred Phungus
Guest
Posts: n/a

 03-19-2010
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

Seebs
Guest
Posts: n/a

 03-19-2010
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 / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Eric Sosman
Guest
Posts: n/a

 03-19-2010
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

lawrence.jones@siemens.com
Guest
Posts: n/a

 03-19-2010
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

Ben Bacarisse
Guest
Posts: n/a

 03-19-2010
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.

Phred Phungus
Guest
Posts: n/a

 03-21-2010
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
Guest
Posts: n/a

 03-21-2010
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

Eric Sosman
Guest
Posts: n/a

 03-21-2010
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

Seebs
Guest
Posts: n/a

 03-21-2010
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 / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Phred Phungus
Guest
Posts: n/a

 03-23-2010
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