J
Jack Klein
This is not correct. "implementation-defined" has a very precise
meaning in the standard. The implementation must choose among a
number of alternatives that are superficially permitted by the
standard, and it must document its choice.
Examples of implementation-defined behavior include:
-- whether right shifting a signed int with a negative value preserves
the sign bit in the result
-- what happens when you assign a signed int value outside the range
of signed char to signed char
Implementation-defined is never allowed to be undefined, or directly
cause undefined behavior.
The other term that causes confusion is "unspecified" behavior, which
again is not the same as undefined. Here the implementation is
required to choose among a number of alternatives allowed by the
standard, but is not required to document its choice and is not
required to be consistent in its choice.
The classic example is the order of evaluation of function arguments.
All the arguments must be evaluated prior to the actual function call,
but the order is unspecified. There's a good reason for it being
unspecified, rather than implementation-defined. Some implementations
use a more efficient method of passing arguments to "ordinary"
functions than they are able to use for variadic functions. This
difference in argument passing methods might cause a difference in
order of evaluation.