nothing much

P

Phred Phungus

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?
 
S

Seebs

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
 
E

Eric Sosman

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

lawrence.jones

Eric Sosman said:
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.
 
B

Ben Bacarisse

Eric Sosman said:
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."
 
P

Phred Phungus

Eric said:
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?
 
P

Phred Phungus

Ben said:
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.
 
E

Eric Sosman

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


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

See Section 3.4.1.
 
S

Seebs

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
 
P

Phred Phungus

Eric said:
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?
 
S

Seebs

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
 
K

Keith Thompson

Phred Phungus said:
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.
 
N

Nick Keighley

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.

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

Phred Phungus

Nick said:
On 24 Mar, 00:49, Keith Thompson <[email protected]> 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.



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

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

Keith Thompson

Phred Phungus said:
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.
 
P

Phred Phungus

Keith said:
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?
 
K

Keith Thompson

Nick Keighley said:
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.
 
P

Phred Phungus

Keith said:
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?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top