nothing much

[Phil Carmody]

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?

When invoked as a C90 or C99 C compiler, no.

Phil

 

[Keith Thompson]

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

It seems clear enough. What part are you having trouble
understanding?

Does gcc support the fortran keyword?

I don't know. gcc comes with fairly extensive documentation.

 

[Phred Phungus]

[...]
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?

When invoked as a C90 or C99 C compiler, no.

Ok.

 

[Phred Phungus]

It seems clear enough. What part are you having trouble
understanding?

The whole thing. The following is a constraint: "thou shalt not divide
by zero."

Regarding the above constraint, thou shalt keep it.

Doesn't the whole thing seem like Ganto's ax (damned if you do/don't)?

I don't know. gcc comes with fairly extensive documentation.

There is no mention of the fortran keyword in gcc.pdf. I think the
gcc-gfortran projects are so joined at the hip that they get this
behavior out of the filetypes of the source.

 

[Keith Thompson]

The whole thing. The following is a constraint: "thou shalt not
divide by zero."

Regarding the above constraint, thou shalt keep it.

Constraints are requirements in the standard in paragraphs explicitly
marked "Constraints".

For example, C99 6.5.2.4 says:

6.5.2.4 Postfix increment and decrement operators

Constraints

1 The operand of the postfix increment or decrement operator shall
have qualified or unqualified real or pointer type and shall
be a modifiable lvalue.

Like most constraints, it expresses the requirement using the word
"shall". The expression ``42'' is not a modifiable lvalue. So if you
write:
42 ++;
you've just violated the constraint, and the compiler is required to
issue a diagnostic message.

On the other hand, C99 6.5.6p9 says:

When two pointers are subtracted, both shall point to elements of
the same array object, or one past the last element of the array
object; the result is the difference of the subscripts of the two
array elements.

Again, the requirement is stated using the word "shall", but it's in
the Semantics subsection, not the Constraints subsection. If you write:

int x;
int y;
ptrdiff_t diff = &x - &y;

you've violated the requirement' but you haven't violated a
constraint. (Rationale: compiler cannot in general detect this
particular error, so it can't reasonably be expected to diagnose
it.) This is where J.2 kicks in (actually section 4 paragraph 2).
Your program's behavior is undefined.

Doesn't the whole thing seem like Ganto's ax (damned if you do/don't)?

Not at all. If you violate such a requirement, your program's
behavior is undefined (and the compiler isn't required to diagnose
the error). If you don't, it isn't.

The "shall" vs. "shall not" just covers two different ways of
expressing a requirement.

There is no mention of the fortran keyword in gcc.pdf.

So there's your answer.

I think the
gcc-gfortran projects are so joined at the hip that they get this
behavior out of the filetypes of the source.

The "fortran" keyword is just one possible mechanism for interfacing
between C and Fortran. As far as I know, it hasn't been widely used
in a very long time.

 

[Chad]

     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.

How could something like 17 / -3 and 17 % -3 produces -5 and -2 or -6
and 1, but something like 17 / 3 and 17 % 3 only produces 5 and 2? Ie,
how come 17 / 3 and 17 % 3 can't produce any other numbers? (Like in
the negative numbers case)

Chad

 

[Seebs]

How could something like 17 / -3 and 17 % -3 produces -5 and -2 or -6
and 1, but something like 17 / 3 and 17 % 3 only produces 5 and 2? Ie,
how come 17 / 3 and 17 % 3 can't produce any other numbers? (Like in
the negative numbers case)

One of them is ambiguous, the other isn't.

Remainder operations and integer division are unambiguous for positive
integers. For negative integers, it's not clear whether you want to just
reverse the signs of both numbers, or change things so the remainder is
always positive. C99 picked one, C89 left it up to the implementation.

-s

 

[Eric Sosman]

[...]

How could something like 17 / -3 and 17 % -3 produces -5 and -2 or -6
and 1, but something like 17 / 3 and 17 % 3 only produces 5 and 2? Ie,
how come 17 / 3 and 17 % 3 can't produce any other numbers? (Like in
the negative numbers case)

For positive integers, we can say "division rounds down"
or "division discards any fraction" and arrive at the same
result. But if the quotient is negative, "round down" and
"discard fraction" give different results (if the division
isn't exact), hence the ambiguity.

For modulus to match up with division, it has to compensate
for whatever adjustment the division made. The important
property is (a/b)*b + (a%b) == a (provided a/b makes sense).
Since "round down" and "discard fraction" give the same result
for positive quotients, the modulus also gives the same result.
For negative quotients, "round down" needs a compensating
positive modulus, while "discard fraction" needs a negative
adjustment.

 

[Phred Phungus]

[...]

How could something like 17 / -3 and 17 % -3 produces -5 and -2 or -6
and 1, but something like 17 / 3 and 17 % 3 only produces 5 and 2? Ie,
how come 17 / 3 and 17 % 3 can't produce any other numbers? (Like in
the negative numbers case)

For positive integers, we can say "division rounds down"
or "division discards any fraction" and arrive at the same
result. But if the quotient is negative, "round down" and
"discard fraction" give different results (if the division
isn't exact), hence the ambiguity.

For modulus to match up with division, it has to compensate
for whatever adjustment the division made. The important
property is (a/b)*b + (a%b) == a (provided a/b makes sense).
Since "round down" and "discard fraction" give the same result
for positive quotients, the modulus also gives the same result.
For negative quotients, "round down" needs a compensating
positive modulus, while "discard fraction" needs a negative
adjustment.

Both Fortran and C round toward the origin.

 

[Eric Sosman]

[... concerning integer division ...]

Both Fortran and C round toward the origin.

C99 rounds toward the origin. C90 rounds toward the
origin *or* toward minus infinity at the implementation's
discretion, as explained earlier in the thread. In both
versions, and with both possible C90 choices, the result
of % "compensates for" whatever rounding / does.

<ot>I don't know Fortran. Long ago I knew FORTRAN and
used it quite a lot, but I've never met the upstart lower-case
pretender to the throne and probably wouldn't recognize it.
<ot>Besides, shouldn't it be ForTran?</ot></ot>