Hi Thiago,

On 5/5/23 02:31, Thiago Macieira via Std-Proposals wrote:
> 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.

I still don't understand how use of static within an inline function
is not UB. Maybe in C++ it's useful. In C, I never found a need for
'static' within an inline function.

>
> This one sounds more like IFNDR:
>
> inline auto f1(int i)
> {
> return [i]() {
> static int j = i;use
> ++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.

Heh, sorry, I don't read that much C++. Lambdas are "there be dragons"
territory for me :).

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

Is there any way to get UB without 'static' in compatible definitions such
as these?

inline void
f(void)
{
 ...
 x = 42; // of course non-volatile, non-aliasing
 y = 7;
 ...
}

inline void
f(void)
{
 ...
 y = 7;
 x = 42;
 ...
}

I guess it would be a matter of defining compatible.

Cheers,
Alex

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