> In C, if a function is defined `static inline` then it will not be callable > from a user-defined inline function with external linkage
Very intersting! Didn't know that. Windows SDK also defines Interlocked functions in winnt.h as inline with external linkage. I guess we should continue doing the same, then :) > Is there a reason why someone wants to do that? Why would someone want to > declare a function whose name is known to be reserved and compiler-specific? Don't know, but winnt.h from Windows SDK does that: #include <Windows.h> #ifdef __INTRIN_H_ #error "intrin.h included" #endif Well, actually it depends on that target architecture. It compiles fine on x86 and x64, but fails on ARM64. Perhaps users want to use some intrinsics but don't want to bring all of intrin.h in the global namespace (quite questionable if you ask me!) BestRegards, Luca ________________________________ Da: LIU Hao Inviato: Giovedì, 11 Giugno, 2026 04:27 A: Luca Bacci; [email protected] Oggetto: Re: R: [Mingw-w64-public] Question: library version of interlocked functions 在 2026-6-10 23:33, Luca Bacci 写道: > Thanks for the insights! > > > There's possibility that some of them might not be inlined > > This brings us another issue however: functions defined in headers should be > 'static always_inline'. Why? > If the compiler decides to emit function calls (say because code takes the > address of the functions) we > can introduce ODR violations. This happens when object files (or static > libraries) are compiled with > different compiler arguments, or if object files (or static libraries) are > compiled with a previous > version of mingw-w64 headers. In C, if a function is defined `static inline` then it will not be callable from a user-defined inline function with external linkage: static inline int static_inline_fn(int x, int y) { return x + y; } // in C99 this is same as `extern inline __attribute__((__gnu_inline__))`. inline int plain_inline_fn(int x) { return static_inline_fn(x, x + 1); } Per standard C (ISO/IEC 9899:2024 N3220): 6.7.5 Function specifiers Constraints 3 An inline definition of a function with external linkage shall not contain, ... and shall not contain, anywhere in the tokens making up the function definition, a reference to an identifier with internal linkage. The code above is a constraint violation which results in undefined behavior. C++ doesn't have this limitation. > Now, it occurs to me that there may be another reason for library functions. > Code targeting MSVC can use > intrinsics even without including intrin.h: > > source.c: > ------------ > long _InterlockedExchange(long volatile* _Target, long _Value); > #pragma intrinsic(_InterlockedExchange) > > int main(void) > { > long value = 0; > return _InterlockedExchange(&value, 1); > } > > This also works on GCC, probably thanks to library implementations in crt.o. Is there a reason why someone wants to do that? Why would someone want to declare a function whose name is known to be reserved and compiler-specific? -- Best regards, LIU Hao _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
