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.