Hi,

On 5/4/23 21:24, Tom Honermann via Std-Proposals wrote:
> On 5/4/23 1:11 PM, sasho648 via Std-Proposals wrote:
>> So why does inline functions need to have the same sequence of tokens
>> in different TU - imagine in a TU there is a preprocessor define that
>> changes the function definition - it would make sense this not to be UB.
>>
>> In C inline functions have internal linkage - it would make the same
>> sense for C++.

What? C inline functions have the same linkage as any other function:
external by default; internal if you use 'static'.

Here's how you should use inline in C:

// foo.h:
inline int
foo(void)
{
 return 42;
}

// foo.c:
extern inline int foo(void);

Here's a great description of how C inline works:
<https://www.greenend.org.uk/rjk/tech/inline.html>

>>
>> Like I don't see a reason requiring inline functions to have the same
>> body - regardless of the statement above.
>
> Taking the address of a (inline or otherwise) function in one
> translation unit must produce a pointer equivalent to that produced in
> another translation unit; they must both point to the same function.
> Thus, you can't have different implementations in different translation
> units.

I don't remember all the details of C++'s inline (and they were always
blurry to me, compared to the clear model of C, where the programmer
has more control/understanding of what happens), but IIRC, each TU that
sees the inline function _and_ has a use that's not inlined emits a weak
symbol, so that the linker chooses one of them.

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.

Cheers,
Alex

>
> Tom.
>