On Mon, Apr 3, 2023, at 09:39, Ville Voutilainen wrote:
> On Mon, 3 Apr 2023 at 17:28, Jonathan Wakely via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>>
>>
>> On Mon, 3 Apr 2023 at 15:22, Henry Miller via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> On Sun, Apr 2, 2023, at 10:04, Ville Voutilainen via Std-Proposals wrote:
>>> > I'm not exactly sure of two things:
>>> > 1) what are you trying to accomplish?
>>> > 2) why?
>>> >
>>> > Libraries are not programs. They are merely binary artifacts that can
>>> > be combined into a program, via a (dynamic) linker. They contain
>>> > translation
>>> > units, but no programs.
>>>
>>> I'm not the OP, but I've long wanted a concept of shared libraries because on my system violated the one-definition-rule is defined behavior. There is set of rules for what definition takes precedence if there is more than one definition in the program. While it is rare I have sometimes found it useful to have a second definition of some symbol in my programs (ie to override some system call), and I want to raise this out of undefined behavior territory.
>>>
>>
>> OK, done.
>>
>> If your system defines it, then it's defined. That's fully conforming with the standard.
>>
>> Consider the -ftrapv and -fwrapv compiler options, which define a specific behaviour for integer overflow. The standard says it's undefined, so any behaviour is allowed, but an implementation can strengthen that and guarantee a particular behaviour. You don't need to change the standard to allow that, it's already allowed.
>>
>> The standard even spells this out explicitly in the definition of undefined behaviour:
>>
>> "Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."
>>
>> ELF symbol interposition rules are an example of behaving in a documented manner characteristic of the environment.
>
> Right. Henry, the UB of ODR violations is not a license to set your
> hair on fire. It's there to allow multiple ways
> of handling that situation, and dynamic loaders are expected to handle
> it differently from static linkers - with a
> loader, you expect it to drop a duplicate and resolve the clash
> somehow, whereas with a static linker you
> usually expect it to diagnose a duplicate rather than guess which one
> to pick. But you can also have a loader
> or a linker that does something else. Trying to specify this would be
> a paper exercise, implementations already
> do what you expect. And trying to nail it down wouldn't work - you
> can't just change every static linker to allow
> duplicates and pick one symbol, that's not what the users of such linkers want.
>
> So - what do you want to accomplish here? And how is that not already
> achieved by practical implementations?

I want to shut up undefined behavior sanitizer for starters. Even raising this to implementation defined would be helpful. Coding standards - for good reason - prohibit undefined behavior. I don't want to explain to management why there should be an exception for this situation.