On Mon, 3 Apr 2023 at 15:52, Henry Miller <hank_at_[hidden]> wrote:

>
>
> 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.


Which sanitizer? How does it complain?

By the time the process starts running, the linker has decided which symbol
to keep, and you only get one symbol in the process.



> 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.
>

If a sanitizer is complaining about something that is well-defined for your
system, that's a bug in the sanitizer. Fix it, don't change the standard.
If the standard changed you'd need a fix to the sanitizer to implement the
new rule anyway, changing the standard is neither necessary nor sufficient.