> And I think this is where we have our differenes. If the "current translation" does not contain function foo(), *then* such a function is looked for in any given libraries [1].
Correct. As long as there is exactly one definition of foo() in the entire program, this is well-defined.
Having bar() defined in the "current translation" and some other library would cause undefined behaviour, where your reasoning would no longer apply.
> Again, the key sentence from 5.1.1.2 #8: Library components
This is not where an "entire program" is referenced.
> I could not find the phrase "full library" (or variations) in the C99 Standard.
I used the word "full" to emphasise that libraries are not considered piece-wise by the standard when it talks about an "entire program".
> Citation please, from the C standard (any one of C89, C99, or C11).
Given that neither the notion of static vs shared libraries, not their organisation, is addressed by the standard, any discussion at this level is not portable, and any use of implementation details, in situations that cause undefined behaviour in the standard, even if it is consistent within the Implementation, is non-conformant. I stress the "use" not the "details".
> It's odd to think of GNU C as not being conformant.
I did not say GNU C was non-coformant (even though it may be). As I explained in earlier messages in this thread, it is the "program", not the "tool", that is non-conformant if the one definition requirement is violated.
> I did some experiments last night on this very subject.
And, as far as I can tell, they were consistent with my description, wherein the linker pulls previously archived object files from a static library, ignoring other object files whenever it can. Which is perfectly fine when there is no more than one definition of any external symbol in the entire program, and is a trivially acceptable form of undefined behaviour otherwise.
> At first, I used Linux but curious, I went and did the same experiments on Solaris
As mentioned by others, Linux and Solaris have a common Unix heritage and adhere to other common standards, so one should expect similar behaviours. So as a demonstration of portability, this is quite weak.
We have an elephant in the room here, and let me just name it: Windows. Once somebody demonstrates similar techniques on Windows, we could talk about real-world portability.
> They are not pre-linked executables. Well, mostly. I know you can execute libc under Linux:
To execute means more than just run something like a program in a shell. And an executable means more than the main executable program file. Any, anyway, the emphasis should have been on "pre-linked" rather than "executable".
> Wow! It worked! Even with func1() and func2() in the same translation unit, func1() is calling func2() from translation unit myfunc2. And it's not Linux! (for the record, it worked under Linux).
Great. Now you might go back to my response to Luiz and address concerns "First" and "Second" there.
> I'm not reading "undefined behavior" there, I see "error" there.
There is no "error" in the standard. What you call an "error", is "undefined behaviour", because "If a ‘‘shall’’ or ‘‘shall not’’ requirement [...] is violated, the behavior is undefined", which I said in my first message in this thread.
Cheers,
V.
