Lew Pitcher <
[email protected]> writes:
[A] single call to a function not defined by your program source
code or by the ISO C standard will invoke "undefined behaviour".
That isn't right. The C standard allows previously translated
translation units "[to] be preserved individually or in libraries."
Those translation units don't have to be your own code or even
necessarily stored, or translated, on the same machine. In
translation phase 8, "[l]ibrary components are linked to satisfy
external references to functions and objects not defined in the
current translation." The C standard doesn't specify how the
libraries are located, or even require that you be able to inspect
them, but clearly does require that libraries be consulted to satisfy
external references. We don't know what code in the libraries will
do, but there is a requirement /on the implementation/ that they be
linked against in phase 8. The presence of that requirement means
that linking to, or calling, such an external reference is not ipso
facto undefined behavior. (Obviously it could be undefined behavior
for other reasons, but not just by virtue of there being a call.)
Not knowing what something will do is not the same as undefined
behavior. The question is Does the C standard give a requirement
about what implementations have to do? In this case it does. An implementation is not free to do whatever it wants just because a
library was previously translated on a different machine. Code in
a library might (emphasis _might_) provoke undefined behavior if it
is called, but that depends on what the library code is, and is not
something an implementation can just arbitrarily chose to do on its
own. It's important to understand the difference.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)