On Thursday, 4 May 2023 17:07:38 PDT Alejandro Colomar via Std-Proposals
wrote:
> However, as long as the contents are reasonably compatible, I don't see
> why it would be problematic. Requiring a token-per-token copy probably
> was more preventing programmers doing stupid things than a real need.
>
> Maybe unspecified behavior instead of undefined behavior could be
> reasonable.

I'd agree on IFNDR, though some changes are clearly UB.

For example:
inline void f1()
{
    static int i = 0;
    ++i;
}

If you changed that int to short, you might end up with a 16-bit increment on
a 32-bit word (worse for big endians than little) or a 32-bit increment on a
16-bit word (bad everywhere). That sounds like UB to me.

This one sounds more like IFNDR:

inline auto f1(int i)
{
    return [i]() {
        static int j = i;
        ++j;
        return &j;
    };
}

This returns a lambda whose call operator itself has a static variable. But if
you insert another lambda before that, such as in:

inline auto f2(int i)
{
    [&]() { ++i; }();
    return [i]() {
        static int j = i;
        ++j;
        return &j;
    };
}

the mangling of that variable will change because the mangling of the lambda
changes. See https://gcc.godbolt.org/z/5qEaWKx4o.

There's no way that this can be implementation-specified or even unspecified
behaviour. Like ODR violations, it has to be at a minimum IFNDR.

Except of course, that all libraries do this ALL the time. Having a stable ABI
while changing inline functions is required up and down the stack, starting
with the Standard Library itself.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering