Why is this code valid C++?

[red floyd]

No, even if it short-circuits, it will not return file pointer. Boolean
expressions (as this one) return only 'true' or 'false', nothing else.
When 'fopen' succeeds and this '||' expression short-circuits, it
returns 'true' which is then cast to 'FILE*' type and stored in 'fp'.
Casting 'true' to 'FILE*' type doesn't make any sense.

This obfuscated technique can be applied properly (see my another
message), but the above is not it.

You're right. I misread the code.

 

[Victor Bazarov]

[...]
In any case, the conversion to pointer is not undefined, but any
attempt to dereference the resulting pointer most certainly is.

It has been discussed several times (that I can remember) that on
some architectures even assigning an invalid value to a pointer may
result in a hardware fault. I don't want to begin that discussion
again.

V

 

[Jack Klein]

[...]
In any case, the conversion to pointer is not undefined, but any
attempt to dereference the resulting pointer most certainly is.

It has been discussed several times (that I can remember) that on
some architectures even assigning an invalid value to a pointer may
result in a hardware fault. I don't want to begin that discussion
again.

V

Then the C++ compiler must do something to prevent the hardware from
generating an exception when an integer type is converted to a
pointer. It may be an invalid pointer, but it may not generate
undefined behavior unless used. If it allows undefined behavior, the
compiler is non-conforming.

The standard specifically states that the conversion is allowed, with
the mapping being implementation-defined.

Any compiler that generates undefined behavior for an operation that
the standard says is implementation-defined is non-conforming.
Undefined behavior is never a conforming option for
implementation-defined behavior.

 

[Jerry Coffin]

Jack Klein wrote:

[ ... ]

Then the C++ compiler must do something to prevent the hardware from
generating an exception when an integer type is converted to a
pointer. It may be an invalid pointer, but it may not generate
undefined behavior unless used. If it allows undefined behavior, the
compiler is non-conforming.

The standard specifically states that the conversion is allowed, with
the mapping being implementation-defined.

Any compiler that generates undefined behavior for an operation that
the standard says is implementation-defined is non-conforming.
Undefined behavior is never a conforming option for
implementation-defined behavior.

Implementation defined behavior is defined only as "Behavior ... that
depends on the implementation and that each implementation shall
document."

As such, the difference between undefined behavior and implementation
defined behavior is substantially smaller than you imply above. The
range of possible responses to each is similar. The real difference is
that implementation defined behavior must be documented, where
undefined behavior does not.

If, however, if the implementation documents that "Attempting to
convert an integer to a pointer may throw an exception.", the
requirements of the standard seem to have been met.

It's open to question that there is a slight difference in the
requirements on the behavior, inasmuch as undefined behavior may give
results that are unpredictable to a degree that documenting them is
essentially impossible, whereas implementation defined behavior must
give results that are documented, and therefore must be predictable
enough to BE documented. The question involved is whether "something
totally unpredictable may happen." would qualify as having documented
the behavior -- some say it is, but I tend to disagree. Regardless of
that, however, I see absolutely NO requirement in the standard that
rules out throwing an exception as implementation defined behavior.