> That's what I was demonstrating: there's undefined behavior ONLY if you use non-shared libraries because the order of units in these libraries is NOT significant.
The C standard has no notion of shared (or not) libraries, so this distinction is irrelevant. Per the standard, multiple external symbols are undefined behaviour no matter how that is managed in any given implementation. The standard has no notion of the "order of units", so what you say here and later about it is meaningless per the standard.
> Only non-shared libraries are not portable if you have multiple units defining the same symbol.
Again, multiple definitions of an external symbol cause undefined behaviour per the C standard, so there is no portability under the standard.
Speaking of real-word portability, so far it has only been demonstrated that one gets consistent results using shared libraries on Windows and (probably) Linux (and, pedantically, it is unknown if this is stable if we use different linkers). The behaviour on Solaris, while consistent with itself, seems different, wherein the patched function seems to be used even when called indirectly, while the former platforms use it only when it is directly called. It is possible that some linker option magic can make the behaviour consistent among all three platforms, but that is yet to be demonstrated.
For the record, the demonstrated behaviour on Solaris seems more useful for patching than that on Linux and Windows, but I suspect there ain't no such thing as a free lunch so we are yet to see what tradeoffs that really involves.
Cheers,
V.
