Date: Mon, 3 Apr 2023 15:27:51 +0100
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.
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.
Received on 2023-04-03 14:28:05