Hi Thiago,

On 2026-06-22T11:34:30-0400, Thiago Macieira via Std-Proposals wrote:
> On Monday, 22 June 2026 08:21:42 Eastern Daylight Time Yexuan Xiao via Std-
> Proposals wrote:
> > Since C does not have namespaces, these libraries use internal linkage to
> > avoid symbol conflicts.
>
> No, that's not why they do it.
>
> They do it because the implementation of non-static inline functions in C are,
> IMNSHO, a mis-feature.

Why? I use extern inline frequently in C, and I don't think there are
any important issues with it.

> When the compiler decides not to inline it, it emits a call to an out-of-line
> function that the developer of the library must have provided. I have never
> seen the explanation of how to just export from one .c file the inline
> implementation for all other TUs (by that I mean I haven't bothered to go
> looking for it).

  // lib.h
 inline int
 func(void)
 {
  return 42;
 }

  // lib.c
 extern inline int func(void);

This is all you need for using inline in C. There's no need to
duplicate any code, or do anything weird. Essentially, you've just
swapped .h and .c files, in that the actual source code is in the .h
file (obviously, as you want the user to be able to read it).

See <https://www.greenend.org.uk/rjk/tech/inline.html>.

> For a non-inlined static inline function, the compiler must emit an out-of-
> line copy because another TU cannot provide an internal-linkage symbol for
> this TU.

This is a limitation of 'static inline', and the reason I use extern
inline: it avoids duplicate binary code.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>