On 20/04/2023 16:51, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 20 April 2023 07:32:39 PDT David Brown via Std-Proposals wrote:
>> C++ already has a solution to this - namespaces. A well-designed C++
>> library would have the global "status" variable inside a namespace.
>> Indeed, it is likely to be in nested namespaces - something like
>> "libspellcheck::internals::status". That will not conflict with any
>> other "status" variable in other namespaces.
>
> That's not a good solution for everything.

Fair enough. I doubt if a "perfect" solution exists - all that is
needed is "good enough for almost all practical purposes".

> It prevents symbol clashes, but it
> doesn't inform the linker whether the symbol should be added to the symbol
> table to be used by other libraries or not. Adding to the symbol table means
> that table grows and, however good the hashing function used may be, you
> increase the overhead of the linking. And given that on ELF systems, such
> symbols are also interposable, that reference is actually doubly inefficient
> because it needs to be indirect via the GOT.
>

That's what ELF symbol visibility is for.

> However, I don't think solving this is the province of the standard. It's
> entirely in the implementation's court.
>

Agreed.