Conflicting INLINE macro naming

[ajkhoury]

The INLINE macro that is defined at blake3_impl.h:30 conflicts with other projects that already define INLINE.

It would be great if you could either add the ability to override INLINE, or rename it to BLAKE3_INLINE or similar.

[oconnor663]

A lot of stuff in that header isn't "namespaced" in the C sense, and the expectation is that users shouldn't need to #include it. (It's our .c files that are supposed to include it.) Is there a particular reason you're including it in your project?

[ajkhoury]

In our case, we have a custom C-Runtime which defines this INLINE macro, which is included from the string and intrinsics headers. We are not including blake3_impl.h.

To avoid this INLINE macro identifier being defined twice, we currently patch the file as such:

diff --git a/common/blake3/blake3_impl.h b/common/blake3/blake3_impl.h
index 3e29e44..2bf37f3 100644
--- a/common/blake3/blake3_impl.h
+++ b/common/blake3/blake3_impl.h
@@ -26,11 +26,13 @@ enum blake3_flags {
 
 // This C implementation tries to support recent versions of GCC, Clang, and
 // MSVC.
+#ifndef INLINE
 #if defined(_MSC_VER)
 #define INLINE static __forceinline
 #else
 #define INLINE static inline __attribute__((always_inline))
 #endif
+#endif
 
 #ifdef __cplusplus
 #define NOEXCEPT noexcept

It would be nice if we did not have to apply this patch to maintain compatibility between this CRT and blake3_impl.h

[BurningEnlightenment]

I recommend reviewing section "7.1.3 Reserved identifiers" of any C standard¹ which prescribes the names a C runtime is allowed to use:

1 Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

• All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
• All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
• Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).
• All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage.
• Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included.

2 No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

None of these criteria reserve the INLINE identifier, i.e. to claim C standard compliance you'll have to rename your macro in your C-Runtime to e.g. _INLINE.

Footnotes

1. C23 changed the wording a bit and moved some parts to section "6.4.2 Identifiers" ↩