[libc-commits] [libc] [libc][stdio] Add fopen_s and bootstrap annex k. (PR #152248)

Aaron Ballman via libc-commits libc-commits at lists.llvm.org
Fri Aug 8 10:36:49 PDT 2025


================
@@ -0,0 +1,19 @@
+//===-- Definition of macros to be used with Annex K functions ------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_LIBC_INCLUDE_LLVM_LIBC_MACROS_ANNEX_K_MACROS_H
+#define LLVM_LIBC_INCLUDE_LLVM_LIBC_MACROS_ANNEX_K_MACROS_H
+
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L &&                \
+    defined(__STDC_WANT_LIB_EXT1__) && __STDC_WANT_LIB_EXT1__ == 1
----------------
AaronBallman wrote:

> I could remove this specific check, but isn't this against the specification? shouldn't we be as compatible with the standard as possible?

I think it's not actually against the specification, but that doesn't mean it's a good idea. :-D Because standards before C11 had no notion of `__STDC_WANT_LIB_EXT1__`, and because that macro is in the reserved identifier space, we can decide that the user defining that macro to 1 means they get Annex K in modes before C11. The user is explicitly opting into a language extension in that case.

Where it gets tricky is, if the user doesn't define that macro then `fopen_s` is not a reserved identifier in modes before C11, which means the user can have an external symbol with that name. So having the symbols in the library at all make for the potential to "steal" an identifier from the user. 

But the reason I brought this up in regards to C++ is because `__STDC_VERSION__` is not defined in C++ and so having a check for that alone would mean you can't get to these interfaces from C++. We could also address that by adding `|| defined(__cplusplus)` though.

https://github.com/llvm/llvm-project/pull/152248


More information about the libc-commits mailing list