Stephen said:
But, it then should allow you to add a value to that integer, as the
code says, no? Is this what you mean by no guarantees of it being
usable?
If you're testing compilers (as you say later on), you really
ought to get yourself a copy of the Standard -- which says (in
section 6.2.3, paragraph 6):
Any pointer type may be converted to an integer type.
Except as previously specified [not relevant here],
the result is implementation-defined. If the result
cannot be represented in the integer type, the behavior
is undefined. The result need not be in the range of
values of any integer type.
So: The result of the conversion is implementation-defined, and
need not be a valid value for an `int', and any attempt to create
an invalid value causes undefined behavior. That's "unusable" in
my book. (Gurus: Contrast this paragraph with the apparently
stronger conditions of 6.3.1.3/3: pointer-to-int can generate
U.B. instead of raising an implementation-defined signal.)
Ok, fine... I agree completely that it is useless, but shouldn't correct
code be generated for it?
It's hard to understand what "correct" means when describing
what might be undefined behavior. I think you need to do two
things before concluding that the generated code is "incorrect:"
You need to consult the compiler's own documentation to find how
it defines the conversion result, and you then need to determine
whether the result is in range for an `int'. Then:
- If the conversion result is defined but out of range,
you have no grounds for complaint. Any and all behaviors
(hence any and all generated code) are "correct."
- If the conversion result is defined and in range, you
may have reason to complain.
- If the conversion result is not defined, you have reason
to complain about the documentation, but not (yet) about
the code generation.
One observation about testing compilers: They usually must
obey several standards, not just one, and some of these may be
just "usual practice" rather than formal standards. That is,
the C Standard represents a sort of "non-negotiable minimum"
for a C implementation, but a C implementation that did *only*
what the Standard required would not enjoy much success. The
prospective users will also want POSIX support and/or Windows
support, they'll want "friendly" behavior when they do things
like clear a pointer to all-bits-zero, they'll want CHAR_BIT
to equal (not exceed) 8, they'll want various guarantees about
signal() behavior, and so on. They will *not* want the strictly-
conforming but user-hostile C compiler of the DeathStation 9000!
Next time you climb into your car, pause and take a look
around. How many of the things you see could be removed without
actually removing the car's ability to get you from Here to
There? Rip out the radio, the air conditioner, the leather
seats, the back seat, the side and rear windows, the power
steering -- you'll still have a strictly-conforming car, but
you might not want to drive it much.