On Mon, 3 Apr 2023 at 15:22, Henry Miller via Std-Proposals <std-proposals@lists.isocpp.org> 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.