Add C11 API with type-safe formatting (#4663) #4671

soumik15630m · 2026-02-07T20:34:45Z

Issues #4663

Summary

Implements a type-safe C11 API for {fmt} using _Generic macros and a fixed-size argument array as discussed in #4663.

Design

Type safety: _Generic macros (FMT_MAKE_ARG) automatically map C types to tagged union
ABI stability: Explicit struct padding, version tracking, stable binary interface
Performance: Fixed-size thread-local array (16 args max), zero allocations for common case
Error handling: Thread-local error strings, negative return codes
Custom types: Callback-based custom formatters with automatic buffer resizing

Architecture: C type → FmtArg → fixed array → basic_format_arg → vformat

Features

All C primitive types (int, float, double, long double, bool, char, pointers)
Format specifiers (padding, precision, hex, alignment, positional args)
Custom formatters via callbacks
Printf-style macros (fmt_printf, fmt_fprintf, fmt_snprintf)
Comprehensive error reporting

Testing

40+ test cases covering:

All primitive types and format specifiers
Buffer overflow safety
Custom formatters
Error conditions
Multi-threading safety (thread-local storage)

Platform Support

C11 required
MSVC 2019+ with /Zc:preprocessor flag (compile-time check included)
GCC/Clang with C11 support
Cross-platform DLL export macros

vitaut

Thanks for the PR!

I'll take a closer look and leave comments inline but first let's rename c.h and c.cc to more descriptive fmt-c.h and fmt-c.cc.

vitaut · 2026-02-08T16:47:38Z

include/fmt/c.h

+#  include <cstddef>
+#  include <cstdint>


This is not needed, we should always use C headers here.

vitaut · 2026-02-08T16:48:33Z

include/fmt/fmt-c.h

+#  if defined(_MSC_VER) && (!defined(_MSVC_TRADITIONAL) || _MSVC_TRADITIONAL)
+#    error \
+        "C API requires MSVC 2019+ with /Zc:preprocessor flag. Add /Zc:preprocessor to your compiler flags."
+#  endif


What is this for?

becuase i used ' VA_ARGS ' and it was causing problems while compiling with legacy compiler so i tested with zc:preprocessor and it worked ...
it need VA_ARGS becuz of that FMT_MAP uses this to split and apply FMT_MAKE_ARG to each one

We don't need this check because the compiler will already give an error if VA_ARGS are not supported. Let's remove.

sure , i'll remove it.
Just to clarify - the legacy preprocessor technically 'supports' VA_ARGS but expands them incorrectly...effectively as a single token , which causes cryptic syntax errors downstream rather than a clear 'unsupported' error.

Interesting. Could you give a godbolt example illustrating the cryptic error?

https://godbolt.org/z/dcd83Goz3

but if we remove the compiler flags the count comes 1

vitaut · 2026-02-08T16:49:07Z

src/c.cc

+#include <string>
+#include <vector>
+
+static const size_t MAX_PACKED_ARGS = FMT_C_MAX_ARGS;


This is not needed because FMT_C_MAX_ARGS can be used directly.

vitaut · 2026-02-08T16:49:35Z

src/c.cc

+static const size_t MAX_PACKED_ARGS = FMT_C_MAX_ARGS;
+
+extern "C" {
+static thread_local std::string g_last_error;


We shouldn't use mutable globals.

I used it - so that fmt_get_c_error can retrieve it ......

but sure , i will change it

just a quick question to remove it should i go with a optional buffer in format functions or just error codes will be enogh

Error codes should be enough.

vitaut · 2026-02-08T16:52:01Z

include/fmt/c.h

+#  define FMT_MAP(f, ...) \
+    FMT_CAT(FMT_MAP_, FMT_NARG(__VA_ARGS__))(f, ##__VA_ARGS__)
+
+#  define fmt_snprintf(buf, cap, fmt, ...)                               \


Please rename to fmt_format since it uses a different syntax from printf.

vitaut · 2026-02-08T16:52:45Z

include/fmt/c.h

+#  define fmt_fprintf(f, fmt, ...)                                       \
+    fmt_c_print(                                                         \
+        f, fmt,                                                          \
+        (FmtArg[]){{FMT_INT}, FMT_MAP(FMT_MAKE_ARG, ##__VA_ARGS__)} + 1, \
+        FMT_NARG(__VA_ARGS__))
+
+#  define fmt_printf(fmt, ...) fmt_fprintf(stdout, fmt, ##__VA_ARGS__)


Let's not include these in the initial implementation and just focus on formatting to a memory buffer.

I’ve implemented the requested changes.

For context, these features were already functioning correctly before the update.

Let me know if there’s anything else you’d like me to revise.
Thanks.

soumik15630m · 2026-02-08T17:04:36Z

sure , i will implement the necessary changes

soumik15630m added 6 commits February 8, 2026 02:02

Add C API wrapper (c) with tests and CMake integration

4987ab3

minor ..consistency fixed

acdb302

NFC: formatting fixes

078663b

NFC: testing ci build tests

0caff00

CI build fixes

33b4de1

MSVC compiler ambiguity addressed between 'char' & 'signed char'

09c75f6

vitaut requested changes Feb 8, 2026

View reviewed changes

vitaut reviewed Feb 8, 2026

View reviewed changes

vitaut requested changes Feb 8, 2026

View reviewed changes

soumik15630m added 2 commits February 9, 2026 00:05

api simplification & minor changes

181ef32

NFC: linting fixes

3a9c8dc

soumik15630m requested a review from vitaut February 8, 2026 19:03

Uh oh!

Add C11 API with type-safe formatting (#4663) #4671

Are you sure you want to change the base?

Add C11 API with type-safe formatting (#4663) #4671

Conversation

soumik15630m commented Feb 7, 2026

Summary

Design

Features

Testing

Platform Support

Uh oh!

vitaut left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

soumik15630m commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vitaut left a comment •

edited

Loading