Date: Mon, 3 Apr 2023 17:39:27 +0300
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?
<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?
Received on 2023-04-03 14:39:39