^{Parent repository:}

This is a small but fully-loaded implementation of C's formatted printing family of functions. It was originally designed by Marco Paland, with the primary use case being in embedded systems - where these functions are unavailable, or when one needs to avoid the memory footprint of linking against a full-fledged libc. The library can be made even smaller by partially excluding some of the supported format specifiers during compilation. The library stands alone, with No external dependencies.

It is a fork of the original mpaland/printf repository by Marco Paland, with multiple bug fixes and a few more features.

If you use a typical libc's sprintf() implementation (or similar function), you are likely to pull in a lot of unwanted library definitions and can bloat code size - typically by as much as 20 KiB. Now, there is a boatload of so called 'tiny' printf()-family implementations around. So why this one? Or rather, why mpaland/printf, and then why this fork?

Well, Marco tried out many of the available printf() implementations, but was disappointed: Some are not thread-safe; some have indirect dependencies on libc or other libraries, making them inconvenient to build and larger when compiled; some only offer extremely limited flag and specifier support; and some produce non-standard-compiled output, failing many tests no found in the repository's test suite.

Marco therefore decided to write his own implementation, with the following goals in mind (I've dropped a few relative to his original description):

• Very small implementation
• NO dependencies on other packages or libraries; no multiple compiled objects, just one object file.
• Support for all standard specifiers and flags, and all width and precision sub-specifiers (see below).
• Support of decimal/floating number representation (with an internal, relatively fast itoa/ftoa implementation)
• Reentrancy and thread-safety; malloc() freeness.
• Clean, robust code.
• Extensive test coverage.
• MIT license

Marco's repository upheld most of these goals - but did not quite make it all of the way. As of mid-2021, it still had many C-standard-non-compliance bugs; the test suite was quite lacking in coverage; some goals were simply discarded (like avoiding global/local-static constants) etc. The repository had become quite popular, but unfortunately, Marco had been otherwise preoccupied; he had not really touched the code in the two years prior; many bug reports were pending, and so were many pull requests from eary adopters who had fixed some of the bugs they had encountered.

The author of this fork was one of the latercomer bug-reporters-and-PR-authors; and when noticing nothing was moving forward, decided to take up the same goals (sans the discarded ones); and integrate the existing forks and available PRs into a single "consensus fork" which would continue where Marco had left off. Along the way, numerous other issues were observed; the build system was improved; the test suite streamlined and expanded; and other contributors also lent a hand (especially @mickjc750). We are now very close to fully realizing the project goals.

Use involving CMake:

1. Use CMake to configure, build and install the library. Then, in another CMake project, use find_package(printf) and make sure the library's install location is in CMake's package search path.

2. Use CMake to configure and build the library. This results in the following files:

   • An object code library file (named printf.a, or printf.so, or printf.dll depending on your platform and choice of static vs dynamic linking)
   • A header file named printf.h
   • (Not strictly necessary) An optional extra header file printf_config.h with the build configuration details.

   Now, in your project, include printf.h and link against the library file, you're all set: There are no dependencies to satisfy or keep track of.

3. Use CMake's FetchContent module to obtain the project source code and make it part of your own project's build, e.g.:

   FetchContent_Declare(printf_library
       GIT_REPOSITORY https://github.com/eyalroz/printf.git
       GIT_TAG v12.34.45 # Replace this with a real available version
   )
   FetchContent_MakeAvailable(printf_library)
   

Use not involving CMake:

4. Copy printf.c and printf.h into your own project, and compile the source however you see fit. Remember that the library requires compilation with the C99 language standard enabled.
5. Include the contents of printf.c into your own code - which can be either C or C . Remember, though, the library is written in the "intersection" of C99 and C 11, so older-standard C programs may not just accept it.

Whichever way you choose to use the library:

• You can have this library stand-in for the C standard library's printf() family of functions, e.g. provide snprintf() instead of snprintf_(), by setting an appropriate preprocessor definition during compilation and use.
• Speaking of the preprocessor definitions which affect the library's behavior - you have to be consistent in their choice when building and when using the library. (The easiest way to do that is just not to change any of them and accept the reasonable defaults.)
• Two of the functions --- printf_() and vprintf_() --- will only be usable if you implement a putchar_(char c) function to underlie them.
• Avoid sprintf() in favor of snprintf() for safety and security - and that goes for the standard C library sprintf() as well:. sprintf() is unaware of the amount of memory allocated for the string it writes into, and will "happily" overflow your buffer; instead of calling it, pass your buffer size to snprintf() - and avoid overflow.

Finally, if you've started using the library in a publicly-available (FOSS or commercial) project, please consider emailing @eyalroz, or open an issue, to announce this.

Options used both in CMake and in the library source code via a preprocessor define:

Within CMake, these options lack the PRINTF_ prefix.

CMake-only options:

Source-only options:

Note: The preprocessor definitions are taken into account when compiling printf.c, not when using the compiled library by including printf.h.

The library offers the following, with the same signatures as in the standard C library (plus an extra underscore):

int printf_(const char* format, ...);
int sprintf_(char* s, const char* format, ...);
int vsprintf_(char* s, const char* format, va_list arg);
int snprintf_(char* s, size_t n, const char* format, ...);
int vsnprintf_(char* s, size_t n, const char* format, va_list arg);
int vprintf_(const char* format, va_list arg);

Note that printf() and vprintf() don't actually write anything on their own: In addition to their parameters, you must provide them with a lower-level putchar_() function which they can call for actual printing. This is part of this library's independence: It is isolated from dealing with console/serial output, files etc.

Two additional functions are provided beyond those available in the standard library:

int fctprintf(void (*out)(char c, void* extra_arg), void* extra_arg, const char* format, ...);
int vfctprintf(void (*out)(char c, void* extra_arg), void* extra_arg, const char* format, va_list arg);

These higher-order functions allow for better flexibility of use: You can decide to do different things with the individual output characters: Encode them, compress them, filter them, append them to a buffer or a file, or just discard them. This is achieved by you passing a pointer to your own state information - through (v)fctprintf() and all the way to your own out() function.

You can configure the library to alias the standard library's names, in which case it exposes printf(), sprintf(), vsprintf() and so on.

If you alias the standard library function names, be careful of GCC/clang's printf() optimizations!: GCC and clang recognize patterns such as printf("%s", str) or printf("%c", ch), and perform a "strength reduction" of sorts by invoking puts(stdout, str) or putchar(ch). If you enable the PRINTF_ALIAS_STANDARD_FUNCTION_NAMES option (see below), and do not ensure your code is compiled with the -fno-builtin-printf option - you might inadvertantly pull in the standard library implementation - either succeeding and depending on it, or failing with a linker error. When using printf as a CMake imported target, that should already be arranged for, but again: Double-check.

Alternatively, you can write short wrappers with your preferred names. This is completely trivial with the v-functions, e.g.:

int my_vprintf(const char* format, va_list va)
{
  return vprintf_(format, va);
}

and is still pretty straightforward with the variable-number-of-arguments functions:

int my_sprintf(char* buffer, const char* format, ...)
{
  va_list va;
  va_start(va, format);
  const int ret = vsprintf_(buffer, format, va);
  va_end(va);
  return ret;
}

A format specifier follows this prototype: %[flags][width][.precision][length]type The following format specifiers are supported:

Notes:

• The %a specifier for hexadecimal floating-point notation (introduced in C99 and C 11) is not currently supported.
• If you want to print the percent sign (%, US-ASCII character 37), use "%%" in your format string.
• The C standard library's printf()-style functions don't accept float arguments, only double's; that is true for this library as well. float's get converted to double's.

The length sub-specifier modifies the length of the data type.

Notes:

• The L modifier, for long double, is not currently supported.
• A "%zd" or "%zi" takes a signed integer of the same size as size_t.
• The implementation currently assumes each of intmax_t, signed size_t, and ptrdiff_t has the same size as long int or as long long int. If this is not the case for your platform, please open an issue.
• The Ixx length modifiers are not in the C (nor C ) standard, but are somewhat popular, as it makes it easier to handle integer types of specific size. One must specify the argument size in bits immediately after the I. The printing is "integer-promotion-safe", i.e. the fact that an int8_t may actually be passed in promoted into a larger int will not prevent it from being printed using its origina value.

Upon successful return, all functions return the number of characters written, excluding the terminating NUL character used to end the string. Functions snprintf() and vsnprintf() don't write more than count bytes, including the terminating NUL character ('\0'). Anyway, if the output was truncated due to this limit, the return value is the number of characters that could have been written. Notice that a value equal or larger than count indicates a truncation. Only when the returned value is non-negative and less than count, the string has been completely written with a terminating NUL. If any error is encountered, -1 is returned.

If NULL is passed for the buffer parameter, nothing is written, but the formatted length is returned. For example:

int length = sprintf(NULL, "Hello, world"); // length is set to 12

The following assumes Marco Paland's original repository remains mostly-inactive in terms of commits.

0. Give this repository a ⭐ (even if you've already starred the original repository).
1. Create an issue and describe your idea. Make sure it is in line with the library's design goals.
2. Fork the repository
3. Create your feature branch (git checkout -b my-new-feature).
4. Implement your feature/idea; don't forget to make sure all existing tests still pass.
5. Add new checks or test-cases to the test suite - both for any problems you have identified and for any new functionality you have introduced.
6. Commit your changes (git commit -a -m "Added some feature")
7. Publish the branch (git push origin my-new-feature)
8. Create a new pull request against this repository. Note: Please don't create a PR without a related issue.

I try to attend to issues and PRs promptly.

This library is published under the terms of the MIT license.