I don't get how the computer arrives at 2^31

[Wojtek Lerch]

Anything that the Standard does not define is undefined.

Then why does it go to such pains to declare things to be "undefined
behavior"? the word undefined appears 182 times in c99, and there are
191 points in J.2 [yes, i counted them. by hand. these things should
really be numbered - at least they contain pointers to the sections they
refer to.]

4#2 If a "shall" or "shall not" requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined behavior is
otherwise indicated in this International Standard by the words "undefined
behavior" or by the omission of any explicit definition of behavior. There
is no difference in emphasis among these three; they all describe "behavior
that is undefined".

 

[Jordan Abel]

Anything that the Standard does not define is undefined.

Then why does it go to such pains to declare things to be "undefined
behavior"? the word undefined appears 182 times in c99, and there are
191 points in J.2 [yes, i counted them. by hand. these things should
really be numbered - at least they contain pointers to the sections they
refer to.]

4#2 If a "shall" or "shall not" requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined behavior is
otherwise indicated in this International Standard by the words "undefined
behavior" or by the omission of any explicit definition of behavior. There
is no difference in emphasis among these three; they all describe "behavior
that is undefined".

I thought the claim i was disputing was that there could be undefined
behavior without the standard making any explicit statement, not that
the explicit statement could be worded some particular other way.

The standard doesn't define the effects of the phase of the moon on the
program - does that mean running a program while the moon is full is
undefined? how about the first quarter?

 

[Ben Pfaff]

Ah, there's the paragraph I was thinking of, but couldn't locate.

I thought the claim i was disputing was that there could be undefined
behavior without the standard making any explicit statement, not that
the explicit statement could be worded some particular other way.

"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior? If
not, then I believe that we are at an impasse--I interpret that
phrase one way, and you do another.

 

[Jordan Abel]

Ah, there's the paragraph I was thinking of, but couldn't locate.


"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior?

there's no explicit definition of what effect the phase of the moon has
on programs [which you not only did not reply to, but snipped.]

As it happens, a positive signed int is permitted in general for
variadic functions that take an unsigned int [same for an unsigned <
INT_MAX for a signed] - The reason i added comp.std.c, was for the
question of whether this same exception would apply to printf.

 

[Wojtek Lerch]

"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior?

there's no explicit definition of what effect the phase of the moon has
on programs [which you not only did not reply to, but snipped.]

If the behaviour of a program or construct is explicitly defined by the
standard, then there's no omission of an explicit definition of behaviour,
even if the definition doesn't mention the phase of the moon.

 

[Ben Pfaff]

"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior?

there's no explicit definition of what effect the phase of the moon has
on programs [which you not only did not reply to, but snipped.]

The standard isn't defining the moon. The behavior of the moon
is indeed undefined by the standard. That doesn't mean that the
behavior of an implementation is dependent on the phase of the
moon.

 

[Chuck F.]

.... snip ...

In my opinion, it is important that we have clearly delineated
areas of doubt and uncertainty, where possible.

That belongs in someones sig files. You omitted fear.

 

[Jordan Abel]

"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior?

there's no explicit definition of what effect the phase of the moon has
on programs [which you not only did not reply to, but snipped.]

The standard isn't defining the moon. The behavior of the moon
is indeed undefined by the standard. That doesn't mean that the
behavior of an implementation is dependent on the phase of the
moon.

But it's not not permitted to be.

regardless, the question i meant to ask for comp.std.c is still
unanswered - does the rule that allows va_arg to accept an unsigned for
signed and vice versa if it's in the right range, also apply to printf?

 

[Richard Heathfield]

Chuck F. said:

That belongs in someones sig files. You omitted fear.

The original is "rigidly defined areas of doubt and uncertainty", and is
from the "Hitch-hikers' Guide to the Galaxy", which was first broadcast in
1976 IIRC.

 

[Ben Pfaff]

Chuck F. said:


The original is "rigidly defined areas of doubt and uncertainty", and is
from the "Hitch-hikers' Guide to the Galaxy", which was first broadcast in
1976 IIRC.

I'm glad that *someone* is paying attention.

 

[Tim Rentsch]

Undefined behaviour -- the return value from pow() is greater
than INT_MAX .

You mean implementation defined, not undefined. ("Implementation
defined" could mean raising an implementation defined signal in
this case, but still implmentation defined.)

 

[Tim Rentsch]

No, this is pretty clear. The type of the argument required for a "%u"
format specifier is "unsigned int". From 7.9.16.1:

"If any argument is not the correct type for the corresponding conversion
specification, the behavior is undefined."

While, for the reasons you mention, most if not all platforms will treat
this as expected, the standard does not explicitly allow it. "int" is not
the correct type.

Presumably you meant 7.19.6.1.

Reading the rules for va_arg in 7.15.1.1, it seems clear that the
Standard intends that an int argument should work for an unsigned int
specifier, if the argument value is representable as an unsigned int.
The way the va_arg rules work make an int argument be "the correct type"
in this case (again, assuming the value is representable as an unsigned
int).

 

[Chad]

Okay, maybe I'm going a bit off topic here, but, I think I'm missing
it. When I go something like:

include <stdio.h>
#include <math.h>

int main(void) {
int i = 0;
double sum = 0;

for (i = 0; i <= 30; i++) {
sum = pow(2.0, i) + sum;
}

printf("The value of c is: %0.0f\n",sum);

return 0;

}

The output is:
$./pw
The value of c is: 2147483647 (not 2147483648).

The way I understood this was that for 32 bits, pow(2.0, 31.0) would
look something like the following:

1111 1111 1111 1111 1111 1111 1111 1111

The first bit would be signed. This means that the value should be the
sum of:
1*2^0 + 1*2^1..... 1*3^30

Why is the value off by one?

Chad

 

[Flash Gordon]

"...or by the omission of any explicit definition of behavior"
does not say that anything not defined is undefined behavior?
there's no explicit definition of what effect the phase of the moon has
on programs [which you not only did not reply to, but snipped.]

The standard isn't defining the moon. The behavior of the moon
is indeed undefined by the standard. That doesn't mean that the
behavior of an implementation is dependent on the phase of the
moon.

But it's not not permitted to be.

It can indeed depend on the phase of the moon where the standard has not
otherwise defined the behaviour. For example, undefined behaviour may
only make daemons fly out of your nose if the moon is not full, and make
werewolves attack you instead on the full moon.

Equally, all calls to printf could fail on the new moon, because the
standard does not disallow it.

Equally it could change the order of evaluation of parameters depending
on the phase of the moon.

However, the number of bits in a char can't change depending on the
phase of the moon, nor can sizeof(int) nor any of the other items
explicitly defined by the standard or which the standard requires that
an implementation document.

regardless, the question i meant to ask for comp.std.c is still
unanswered - does the rule that allows va_arg to accept an unsigned for
signed and vice versa if it's in the right range, also apply to printf?

I would argue that it is undefined because in the specific case of
printf it is explicitly stated that it the type is different it is
undefined. After all, printf might not be implemented in C and so might
make assumptions that code written in C is not allowed to make. Although
I can't think how it could manage to break this.

 

[Chad]

Okay, maybe I'm going a bit off topic here, but, I think I'm missing
it. When I go something like:

include <stdio.h>
#include <math.h>

int main(void) {
int i = 0;
double sum = 0;

for (i = 0; i <= 30; i++) {
sum = pow(2.0, i) + sum;
}

printf("The value of c is: %0.0f\n",sum);

return 0;

}

The output is:
$./pw
The value of c is: 2147483647 (not 2147483648).

The way I understood this was that for 32 bits, pow(2.0, 31.0) would
look something like the following:

1111 1111 1111 1111 1111 1111 1111 1111

The first bit would be signed. This means that the value should be the
sum of:
1*2^0 + 1*2^1..... 1*3^30

Why is the value off by one?

Chad

I mean sum of 1*2^0 + 1*2^1..... 1*2^30.

Chad

 

[Chad]

Okay, maybe I'm going a bit off topic here, but, I think I'm missing
it. When I go something like:

include <stdio.h>
#include <math.h>

int main(void) {
int i = 0;
double sum = 0;

for (i = 0; i <= 30; i++) {
sum = pow(2.0, i) + sum;
}

printf("The value of c is: %0.0f\n",sum);

return 0;

}

The output is:
$./pw
The value of c is: 2147483647 (not 2147483648).

The way I understood this was that for 32 bits, pow(2.0, 31.0) would
look something like the following:

1111 1111 1111 1111 1111 1111 1111 1111

The first bit would be signed. This means that the value should be the
sum of:
1*2^0 + 1*2^1..... 1*3^30

Why is the value off by one?

Chad

I mean sum of 1*2^0 + 1*2^1..... 1*2^30.

Chad

 

[Mark McIntyre]

I'm glad that *someone* is paying attention.

Though fear would add to our weapons... I'll come in again.

 

[kuyper]

Jordan Abel wrote:
....

Things are only undefined because the standard says that they are
undefined, not for any other reason. ...

As it happens, the standard explicitly states that when there is no
explicit definition of the behavior, it is undefined. There is no part
of the standard anywhere that specifies the behavior of the printf()
family of functions when there is a mis-match between the format code
and the actual promoted type of the arguments.

... As it happens, this is in fact the
case, 7.19.6.1p9 "If any argument is not the correct type for the
corresponding conversion specification, the behavior is undefined".

However, if we assume that printf is a variadic function implemented
along the lines of the stdarg.h macros, we see 7.15.1.1p2 "...except for
the following cases: - one type is a signed integer type, the other type
is the corresponding unsigned integer type, and the value is
representable in both types" - In this case, the value is not, but "%u
is for unsigned ints" as a blanket statement would seem to be incorrect.
comp.std.c added - do the signed/unsigned exception, and the char*/void*
one, to va_arg type rules also apply to printf?

The standard doesn't require the use of the <stdarg.h> macros. Whatever
method is used must be interface compatible with those macros,
otherwise suitably cast function pointers couldn't be used to invoke
printf(). However, since the standard specifies that the behavior for
printf() is undefined in this case, that allows it do something other
than, or in addition to, using stdarg.h macros. For instance, the
implementation might provide as an extension some way of querying what
the actual type an argument was, even though the standard provides no
method of doing so. If printf() is implemented using that extension, it
can identify the type mis-match, and because the behavior is explicitly
undefined when there is such a mismatch, it's permitted to do whatever
the implementors want it to do; the most plausible choice would be a
run-time diagnostic sent to stderr; though assert() and abort() are
other reasonable options.

Incidentally, my copy of some c89 draft says that %u takes an int and
converts it to unsigned. c99 changes this to take an unsigned int. There
are several possibilities: Perhaps they screwed up (but the c99
rationale does not comment on this), or they thought the difference was
insignificant enough not to matter.

I think that it was felt that the difference was important, and
desireable, but not worthy of an explicit mention in the Rationale. Do
you think the C99 specification is undesireable?

 

[kuyper]

I thought the claim i was disputing was that there could be undefined
behavior without the standard making any explicit statement, not that
the explicit statement could be worded some particular other way.

Well, the "particular other way" being referred to in this case is "by
the omission of any explicit definition of behavior". That seems to
fit "without the standard making any explicit statement", as far as I
can see.

The standard doesn't define the effects of the phase of the moon on the
program - does that mean running a program while the moon is full is
undefined? how about the first quarter?

The behavior of some C programs is defined by the standard, regardless
of the phase of the moon, so they must have that behavior. However, it
is indeed permitted for the phase of the moon to affect any aspect of
the behavior that is NOT specified by the standard. For instance, it's
permitted to affect the speed with which computations are carried out.
Whenever the behavior is implementation-defined, it is permissible for
the implementation to define the behavior as depending upon the phase
of the moon.

The behavior of printf() is defined only for those cases where the
types match. The standard nowhere defines what they do when there's a
mismatch.

 

[Wojtek Lerch]

regardless, the question i meant to ask for comp.std.c is still
unanswered - does the rule that allows va_arg to accept an unsigned for
signed and vice versa if it's in the right range, also apply to printf?

There was a discussion about that here in comp.std.c a while ago. The
bottom line is, I think, that it's pretty clear that the intention was to
allow it, but there's no agreement about whether the normative text actually
says it:

http://groups.google.com/group/comp.std.c/browse_frm/thread/22ec94bc9cf05460/216d6f482bc2a6fa