Minimal, type safe printf replacement library for C++

Overview

tinyformat.h

A minimal type safe printf() replacement

tinyformat.h is a type safe printf replacement library in a single C++ header file. If you've ever wanted printf("%s", s) to just work regardless of the type of s, tinyformat might be for you. Design goals include:

  • Type safety and extensibility for user defined types.
  • C99 printf() compatibility, to the extent possible using std::ostream
  • POSIX extension for positional arguments
  • Simplicity and minimalism. A single header file to include and distribute with your projects.
  • Augment rather than replace the standard stream formatting mechanism
  • C++98 support, with optional C++11 niceties

Build status, master branch: Linux/OSX build Windows build

Quickstart

To print a date to std::cout:

std::string weekday = "Wednesday";
const char* month = "July";
size_t day = 27;
long hour = 14;
int min = 44;

tfm::printf("%s, %s %d, %.2d:%.2d\n", weekday, month, day, hour, min);

POSIX extension for positional arguments is available. The ability to rearrange formatting arguments is an important feature for localization because the word order may vary in different languages.

Previous example for German usage. Arguments are reordered:

tfm::printf("%1$s, %3$d. %2$s, %4$d:%5$.2d\n", weekday, month, day, hour, min);

The strange types here emphasize the type safety of the interface, for example it is possible to print a std::string using the "%s" conversion, and a size_t using the "%d" conversion. A similar result could be achieved using either of the tfm::format() functions. One prints on a user provided stream:

tfm::format(std::cerr, "%s, %s %d, %.2d:%.2d\n",
            weekday, month, day, hour, min);

The other returns a std::string:

std::string date = tfm::format("%s, %s %d, %.2d:%.2d\n",
                               weekday, month, day, hour, min);
std::cout << date;

It is safe to use tinyformat inside a template function. For any type which has the usual stream insertion operator<< defined, the following will work as desired:

template<typename T>
void myPrint(const T& value)
{
    tfm::printf("My value is '%s'\n", value);
}

(The above is a compile error for types T without a stream insertion operator.)

Function reference

All user facing functions are defined in the namespace tinyformat. A namespace alias tfm is provided to encourage brevity, but can easily be disabled if desired.

Three main interface functions are available: an iostreams-based format(), a string-based format() and a printf() replacement. These functions can be thought of as C++ replacements for C's fprintf(), sprintf() and printf() functions respectively. All the interface functions can take an unlimited number of input arguments if compiled with C++11 variadic templates support. In C++98 mode, the number of arguments must be limited to some fixed upper bound which is currently 16 as of version 1.3. Supporting more arguments is quite easy using the in-source code generator based on cog.py - see the source for details.

The format() function which takes a stream as the first argument is the main part of the tinyformat interface. stream is the output stream, formatString is a format string in C99 printf() format, and the values to be formatted have arbitrary types:

template<typename... Args>
void format(std::ostream& stream, const char* formatString,
            const Args&... args);

The second version of format() is a convenience function which returns a std::string rather than printing onto a stream. This function simply calls the main version of format() using a std::ostringstream, and returns the resulting string:

template<typename... Args>
std::string format(const char* formatString, const Args&... args);

Finally, printf() and printfln() are convenience functions which call format() with std::cout as the first argument; both have the same signature:

template<typename... Args>
void printf(const char* formatString, const Args&... args);

printfln() is the same as printf() but appends an additional newline for convenience - a concession to the author's tendency to forget the newline when using the library for simple logging.

Format strings and type safety

Tinyformat parses C99 format strings to guide the formatting process --- please refer to any standard C99 printf documentation for format string syntax. In contrast to printf, tinyformat does not use the format string to decide on the type to be formatted so this does not compromise the type safety: you may use any format specifier with any C++ type. The author suggests standardising on the %s conversion unless formatting numeric types.

Let's look at what happens when you execute the function call:

tfm::format(outStream, "%+6.4f", yourType);

First, the library parses the format string, and uses it to modify the state of outStream:

  1. The outStream formatting flags are cleared and the width, precision and fill reset to the default.
  2. The flag '+' means to prefix positive numbers with a '+'; tinyformat executes outStream.setf(std::ios::showpos)
  3. The number 6 gives the field width; execute outStream.width(6).
  4. The number 4 gives the precision; execute outStream.precision(4).
  5. The conversion specification character 'f' means that floats should be formatted with a fixed number of digits; this corresponds to executing outStream.setf(std::ios::fixed, std::ios::floatfield);

After all these steps, tinyformat executes:

outStream << yourType;

and finally restores the stream flags, precision and fill.

What happens if yourType isn't actually a floating point type? In this case the flags set above are probably irrelevant and will be ignored by the underlying std::ostream implementation. The field width of six may cause some padding in the output of yourType, but that's about it.

Special cases for "%p", "%c" and "%s"

Tinyformat normally uses operator<< to convert types to strings. However, the "%p" and "%c" conversions require special rules for robustness. Consider:

uint8_t* pixels = get_pixels(/* ... */);
tfm::printf("%p", pixels);

Clearly the intention here is to print a representation of the pointer to pixels, but since uint8_t is a character type the compiler would attempt to print it as a C string if we blindly fed it into operator<<. To counter this kind of madness, tinyformat tries to static_cast any type fed to the "%p" conversion into a const void* before printing. If this can't be done at compile time the library falls back to using operator<< as usual.

The "%c" conversion has a similar problem: it signifies that the given integral type should be converted into a char before printing. The solution is identical: attempt to convert the provided type into a char using static_cast if possible, and if not fall back to using operator<<.

The "%s" conversion sets the boolalpha flag on the formatting stream. This means that a bool variable printed with "%s" will come out as true or false rather than the 1 or 0 that you would otherwise get.

Incompatibilities with C99 printf

Not all features of printf can be simulated simply using standard iostreams. Here's a list of known incompatibilities:

  • The "%a" and "%A" hexadecimal floating point conversions ignore precision as stream output of hexfloat (introduced in C++11) ignores precision, always outputting the minimum number of digits required for exact representation. MSVC incorrectly honors stream precision, so we force precision to 13 in this case to guarentee lossless roundtrip conversion.
  • The precision for integer conversions cannot be supported by the iostreams state independently of the field width. (Note: this is only a problem for certain obscure integer conversions; float conversions like %6.4f work correctly.) In tinyformat the field width takes precedence, so the 4 in %6.4d will be ignored. However, if the field width is not specified, the width used internally is set equal to the precision and padded with zeros on the left. That is, a conversion like %.4d effectively becomes %04d internally. This isn't correct for every case (eg, negative numbers end up with one less digit than desired) but it's about the closest simple solution within the iostream model.
  • The "%n" query specifier isn't supported to keep things simple and will result in a call to TINYFORMAT_ERROR.
  • The "%ls" conversion is not supported, and attempting to format a wchar_t array will cause a compile time error to minimise unexpected surprises. If you know the encoding of your wchar_t strings, you could write your own std::ostream insertion operator for them, and disable the compile time check by defining the macro TINYFORMAT_ALLOW_WCHAR_STRINGS. If you want to print the address of a wide character with the "%p" conversion, you should cast it to a void* before passing it to one of the formatting functions.

Error handling

By default, tinyformat calls assert() if it encounters an error in the format string or number of arguments. This behaviour can be changed (for example, to throw an exception) by defining the TINYFORMAT_ERROR macro before including tinyformat.h, or editing the config section of the header.

Formatting user defined types

User defined types with a stream insertion operator will be formatted using operator<<(std::ostream&, T) by default. The "%s" format specifier is suggested for user defined types, unless the type is inherently numeric.

For further customization, the user can override the formatValue() function to specify formatting independently of the stream insertion operator. If you override this function, the library will have already parsed the format specification and set the stream flags accordingly - see the source for details.

Wrapping tfm::format() inside a user defined format function

Suppose you wanted to define your own function which wraps tfm::format. For example, consider an error function taking an error code, which in C++11 might be written simply as:

template<typename... Args>
void error(int code, const char* fmt, const Args&... args)
{
    std::cerr << "error (code " << code << ")";
    tfm::format(std::cerr, fmt, args...);
}

Simulating this functionality in C++98 is pretty painful since it requires writing out a version of error() for each desired number of arguments. To make this bearable tinyformat comes with a set of macros which are used internally to generate the API, but which may also be used in user code.

The three macros TINYFORMAT_ARGTYPES(n), TINYFORMAT_VARARGS(n) and TINYFORMAT_PASSARGS(n) will generate a list of n argument types, type/name pairs and argument names respectively when called with an integer n between 1 and 16. We can use these to define a macro which generates the desired user defined function with n arguments. This should be followed by a call to TINYFORMAT_FOREACH_ARGNUM to generate the set of functions for all supported n:

#define MAKE_ERROR_FUNC(n)                                    \
template<TINYFORMAT_ARGTYPES(n)>                              \
void error(int code, const char* fmt, TINYFORMAT_VARARGS(n))  \
{                                                             \
    std::cerr << "error (code " << code << ")";               \
    tfm::format(std::cerr, fmt, TINYFORMAT_PASSARGS(n));      \
}
TINYFORMAT_FOREACH_ARGNUM(MAKE_ERROR_FUNC)

Sometimes it's useful to be able to pass a list of format arguments through to a non-template function. The FormatList class is provided as a way to do this by storing the argument list in a type-opaque way. For example:

template<typename... Args>
void error(int code, const char* fmt, const Args&... args)
{
    tfm::FormatListRef formatList = tfm::makeFormatList(args...);
    errorImpl(code, fmt, formatList);
}

What's interesting here is that errorImpl() is a non-template function so it could be separately compiled if desired. The FormatList instance can be used via a call to the vformat() function (the name chosen for semantic similarity to vprintf()):

void errorImpl(int code, const char* fmt, tfm::FormatListRef formatList)
{
    std::cerr << "error (code " << code << ")";
    tfm::vformat(std::cout, fmt, formatList);
}

The construction of a FormatList instance is very lightweight - it defers all formatting and simply stores a couple of function pointers and a value pointer per argument. Since most of the actual work is done inside vformat(), any logic which causes an early exit of errorImpl() - filtering of verbose log messages based on error code for example - could be a useful optimization for programs using tinyformat. (A faster option would be to write any early bailout code inside error(), though this must be done in the header.)

Benchmarks

Compile time and code bloat

The script bloat_test.sh included in the repository tests whether tinyformat succeeds in avoiding compile time and code bloat for nontrivial projects. The idea is to include tinyformat.h into 100 translation units and use printf() five times in each to simulate a medium sized project. The resulting executable size and compile time (g++-4.8.2, linux ubuntu 14.04) is shown in the following tables, which can be regenerated using make bloat_test:

Non-optimized build

test name compiler wall time executable size (stripped)
libc printf 1.8s 48K (36K)
std::ostream 10.7s 96K (76K)
tinyformat, no inlines 18.9s 140K (104K)
tinyformat 21.1s 220K (180K)
tinyformat, c++0x mode 20.7s 220K (176K)
boost::format 70.1s 844K (736K)

Optimized build (-O3 -DNDEBUG)

test name compiler wall time executable size (stripped)
libc printf 2.3s 40K (28K)
std::ostream 11.8s 104K (80K)
tinyformat, no inlines 23.0s 128K (104K)
tinyformat 32.9s 128K (104K)
tinyformat, c++0x mode 34.0s 128K (104K)
boost::format 147.9s 644K (600K)

For large projects it's arguably worthwhile to do separate compilation of the non-templated parts of tinyformat, as shown in the rows labelled tinyformat, no inlines. These were generated by putting the implementation of vformat (detail::formatImpl() etc) it into a separate file, tinyformat.cpp. Note that the results above can vary considerably with different compilers. For example, the -fipa-cp-clone optimization pass in g++-4.6 resulted in excessively large binaries. On the other hand, the g++-4.8 results are quite similar to using clang++-3.4.

Speed tests

The following speed tests results were generated by building tinyformat_speed_test.cpp on an Intel core i7-2600K running Linux Ubuntu 14.04 with g++-4.8.2 using -O3 -DNDEBUG. In the test, the format string "%0.10f:%04d:%+g:%s:%p:%c:%%\n" is filled 2000000 times with output sent to /dev/null; for further details see the source and Makefile.

test name run time
libc printf 1.20s
std::ostream 1.82s
tinyformat 2.08s
boost::format 9.04s

It's likely that tinyformat has an advantage over boost.format because it tries reasonably hard to avoid formatting into temporary strings, preferring instead to send the results directly to the stream buffer. Tinyformat cannot be faster than the iostreams because it uses them internally, but it comes acceptably close.

Rationale

Or, why did I reinvent this particularly well studied wheel?

Nearly every program needs text formatting in some form but in many cases such formatting is incidental to the main purpose of the program. In these cases, you really want a library which is simple to use but as lightweight as possible.

The ultimate in lightweight dependencies are the solutions provided by the C++ and C libraries. However, both the C++ iostreams and C's printf() have well known usability problems: iostreams are hopelessly verbose for complicated formatting and printf() lacks extensibility and type safety. For example:

// Verbose; hard to read, hard to type:
std::cout << std::setprecision(2) << std::fixed << 1.23456 << "\n";
// The alternative using a format string is much easier on the eyes
tfm::printf("%.2f\n", 1.23456);

// Type mismatch between "%s" and int: will cause a segfault at runtime!
printf("%s", 1);
// The following is perfectly fine, and will result in "1" being printed.
tfm::printf("%s", 1);

On the other hand, there are plenty of excellent and complete libraries which solve the formatting problem in great generality (boost.format and fastformat come to mind, but there are many others). Unfortunately these kind of libraries tend to be rather heavy dependencies, far too heavy for projects which need to do only a little formatting. Problems include

  1. Having many large source files. This makes a heavy dependency unsuitable to bundle within other projects for convenience.
  2. Slow build times for every file using any sort of formatting (this is very noticeable with g++ and boost/format.hpp. I'm not sure about the various other alternatives.)
  3. Code bloat due to instantiating many templates

Tinyformat tries to solve these problems while providing formatting which is sufficiently general and fast for incidental day to day uses.

License

For minimum license-related fuss, tinyformat.h is distributed under the boost software license, version 1.0. (Summary: you must keep the license text on all source copies, but don't have to mention tinyformat when distributing binaries.)

Author and acknowledgements

Tinyformat is written and maintained by Chris Foster, with various contributions gratefully recieved from the community.

Originally the implementation was inspired by the way boost::format uses stream based formatting to simulate most of the printf() syntax, and Douglas Gregor's toy printf() in an early variadic template example.

Bugs

Here's a list of known bugs which are probably cumbersome to fix:

  • Field padding won't work correctly with complicated user defined types. For general types, the only way to do this correctly seems to be format to a temporary string stream, check the length, and finally send to the output stream with padding if necessary. Doing this for all types would be quite inelegant because it implies extra allocations to make the temporary stream. A workaround is to add logic to operator<<() for composite user defined types so they are aware of the stream field width.
Comments
  • tfm::format(

    tfm::format("%+d", 0) gives the wrong result on OSX

    As documented here

    https://github.com/OpenImageIO/oiio/pull/477

    OSX has a buggy version of the STL which causes tinyformat to omit the + sign for the tfm::format("%+d", 0) conversion.

    opened by c42f 13
  • Segmentation Fault with Intel Compiler

    Segmentation Fault with Intel Compiler

    I came across a very strange problem in tinyformat v2.2.0. Even the most trivial of examples

    #include "tinyformat.h"
    
    int main(int argc, char** argv) {
      auto str = tfm::format("Got %d arguments", argc);
      return str.size();
    }
    

    causes a segfault when compiling with icpc -std=gnu++11 -O0. There is no segfault when compiling with any optimization level greater than 0. The backtrace is

    #0  0x00007fffffff9808 in ?? ()
    #1  0x000000000040216f in tinyformat::detail::FormatArg::format (this=0x7fffffff9768, out=..., fmtBegin=0x404738 "%d arguments", fmtEnd=0x40473a " arguments", ntrunc=-1) at tinyformat.h:513
    #2  0x0000000000403994 in tinyformat::detail::formatImpl (out=..., fmt=0x404738 "%d arguments", formatters=0x7fffffff9768, numFormatters=1) at tinyformat.h:812
    #3  0x0000000000403ec6 in tinyformat::vformat (out=..., fmt=0x404734 "Got %d arguments", list=...) at tinyformat.h:956
    #4  0x0000000000403fb5 in tinyformat::format<int> (out=..., fmt=0x404734 "Got %d arguments", [email protected]: 1) at tinyformat.h:966
    #5  0x0000000000403f49 in tinyformat::format<int> (fmt=0x404734 "Got %d arguments", [email protected]: 1) at tinyformat.h:975
    #6  0x00000000004018e2 in main (argc=1, argv=0x7fffffff9ac8) at tfm_bug.cc:4
    

    I tried with two different versions of icpc

    • icpc (ICC) 18.0.3 20180410 on RHEL7 (3.10.0-957.27.2.el7.x86_64)
    • icpc (ICC) 19.0.5.281 20190815 RHEL7 (3.10.0-1062.1.2.el7.x86_64)
    opened by dakep 10
  • handling the 0-variable frmat

    handling the 0-variable frmat

    In your code I see:

    //------------------------------------------------------------------------------
    // Private format function on top of which the public interface is implemented.
    // We enforce a mimimum of one value to be formatted to prevent bugs looking like
    //
    //   const char* myStr = "100% broken";
    //   printf(myStr);   // Parses % as a format specifier
    

    And I understand why. However, having a version that allows it and putting trust back to the programmer is more useful to me.

    In Rcpp11, https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/utils/tinyformat.h @kevinushey and I have modified it so that it handles the case where there a no variable to format.

    The alternative would have been to come up with dispatch based on the sizeof...(Args) in or code.

    Anyway, what I've done is this:

    template <typename... Args> struct Formatter{
      inline void operator()(FormatIterator& fmtIter){
        fmtIter.finish() ;
      }
    } ;
    
    template <typename T1, typename... Args>
    struct Formatter<T1, Args...>{
      inline void operator()( FormatIterator& fmtIter, const T1& value1, const Args&... args){
        fmtIter.accept(value1);
        Formatter<Args...>()(fmtIter, args...);  
      }
    } ;
    

    If you strongly believe that this case should not be handled, that's fine. Otherwise I can prepare a pull request. (this is more work I suppose because in Rcpp11 we only kept the C++11 part as we assume C++11 support.

    BTW, would it make sense to provide a C++11 only variant of tinyformat for those who can assume C++11.

    opened by romainfrancois 10
  • puts

    puts

    If this is supported:

    tfm::printf("%s", 9);
    

    might as well support this too:

    tfm::puts(9);
    

    http://pubs.opengroup.org/onlinepubs/9699919799/functions/puts.html

    opened by ghost 6
  • printf issue with VS2013 x64

    printf issue with VS2013 x64

    MSVC is generating format errors for ints when using tiny format::printf in Visual Studio 2013 Update 3 targeting x64 using this code:

    std::string weekday = "Wednesday";
    const char* month = "July";
    size_t day = 27;
    long hour = 14;
    int min = 44;
    tfm::printf("%s, %s %d, %.2d:%.2d\n", weekday, month, day, hour, min);
    
    warning C4313: 'printf' : '%d' in format string conflicts with argument 3 of type 'const size_t *'
    

    I get this warning for each int. If I build targeting 32-bit it works fine. I'm not sure what's going on. It seems to think the argument type is a pointer. I wonder if this is a bug?

    If I use tfm::format to generate a string, it works fine.

    opened by kainjow 6
  • Consider printfln() convenience function

    Consider printfln() convenience function

    I'm considering adding a printfln() function for convenience which simply appends a "\n" to the usual printf() output. This would be especially useful for ad hoc debug logging. Naming wise, this is consistent with some other languages such as D which has writef/writefln. No obvious precedent in the C and C++ world come to mind.

    On the downside, it's a new public API for something that's trivial to do with plain old printf("foo\n"), but sometimes I still forget the newline, especially when using alongside a logging API which appends newlines automatically.

    There's a small but nonzero number of people watching tinyformat - thoughts anyone?

    opened by c42f 6
  • Add POSIX extension for positional arguments

    Add POSIX extension for positional arguments

    The ability to rearrange formatting arguments is an important feature for localization because the word order may vary in different languages.

    Without this we can't use tinyformat in projects where localization is required.

    Example of reordering arguments in date (American to Germany format): tfm::printf("%1$s, %3$d. %2$s, %4$d:%5$.2d\n", weekday, month, day, hour, min);

    opened by jrohel 5
  • Linker warning on OS X

    Linker warning on OS X

    I have a linker warning on OS X:

    ld: warning: direct access in tinyformat::detail::FormatArg::FormatArg(unsigned long const&) to global weak symbol void tinyformat::detail::FormatArg::formatImpl(std::__1::basic_ostream<char, std::1::char_traits >&, char const, char const, int, void const*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

    Do you have an idea how to fix it?

    opened by beemaster 5
  • Empty FormatArg() constructor doesn't initialize members

    Empty FormatArg() constructor doesn't initialize members

    https://github.com/c42f/tinyformat/blob/46a6d778e7abafa057efc546197603d32719bfc5/tinyformat.h#L490

    This confuses Coverity, and also looks unsafe:

    screenshot from 2017-10-02 09-25-09

    Reference: https://github.com/RcppCore/Rcpp/issues/760

    opened by krlmlr 4
  • Warning in XCode 7

    Warning in XCode 7

    After updating to XCode 7 I have following warning:

    tinyformat.h:864:27: error: field 'm_formatterStore' is uninitialized when used here [-Werror,-Wuninitialized]
                : FormatList(&m_formatterStore[0], N),
    

    I wish I could do a pull request but I can not wrap my head around how this could be fixed.

    opened by beemaster 4
  • executable size is too large

    executable size is too large

    header only is not an advantage for safe printf, A more efficient implementation should just use variadic template to compute a type-signature-array, and pass to an external_linkage_safe_printf function along with other parameters

    opened by rockeet 4
  • Not enough conversion specifiers in format string

    Not enough conversion specifiers in format string

    I'm attempting to run a bitcoin fork in LXD/LXC (linux containers)

    I ~~get~~see errors when I watch tail the debug.log and when I run bitcoin-cli getinfo in the json output errors value:

    EXCEPTION: St13runtime_error \ntinyformat: Not enough conversion specifiers in format string \nallsafe in ProcessMessages() \n

    The fork: https://github.com/Artinvest/Allsafe/releases

    How do I fix this?

    opened by benzmuircroft 4
  • Different output for earlier compilers

    Different output for earlier compilers

    The following code will print different output on different compilers:

    enum Number : uint8_t {
            FOO = 111, 
    };
    
    int main(){
        std::cout << tinyformat::format("%s", Number::FOO) << std::endl;
    }
    

    gcc 9 (and earlier): 111 gcc 10 (and later): o clang 9 (and earlier): 111 gcc 10 (and later): o

    opened by MarcoFalke 1
  • Allow to print any free or member class pointer

    Allow to print any free or member class pointer

    fix #68 - Cannot print function pointer

    #include<iostream>
    #include "tinyformat.h"
    
    struct test_debugger { void var() {} };
    void fun_void_void(){};
    void fun_void_double(double d){};
    double fun_double_double(double d){return d;}
    
    int main(void) {
        int* var;
    
        std::cout << std::boolalpha;
        std::cout << tfm::format( "0. %s", &var ) << std::endl;
        std::cout << tfm::format( "1. %s", &fun_void_void ) << std::endl;
        std::cout << tfm::format( "2. %s", &fun_void_double ) << std::endl;
        std::cout << tfm::format( "3. %s", &fun_double_double ) << std::endl;
        std::cout << tfm::format( "4. %s", &test_debugger::var ) << std::endl;
        return 0;
    }
    

    Prints:

    $ g++ -o main.exe -g -ggdb test.cpp --std=c++98 && ./main.exe
    0. 0xffffcbb0
    1. 0x100401100
    2. 0x100401107
    3. 0x100401113
    4. 0x100405f10
    
    $ g++ -o main.exe -g -ggdb test.cpp --std=c++11 && ./main.exe
    0. 0xffffcbb0
    1. 0x100401100
    2. 0x100401107
    3. 0x100401113
    4. 0x100405b70
    
    opened by evandrocoan 1
  • error: invalid static_cast from type ‘const void*’ to type ‘void (*)()’

    error: invalid static_cast from type ‘const void*’ to type ‘void (*)()’

    #include<iostream>
    #include "tinyformat.h"
    
    void fun_void_void(){};
    
    int main(void) {
        std::cout << std::boolalpha;
        std::cout << fun_void_void << std::endl;
        std::cout << tfm::format( "1. %s", fun_void_void ) << std::endl;
        return 0;
    }
    

    Calling std::cout << fun_void_void works fine, but tfm::format( "1. %s", fun_void_void ) (either %s or %p) results in:

    $ g++ -o main.exe -g -ggdb test_debugger4.cpp --std=c++11 && ./main.exe
    In file included from test_debugger4.cpp:2:0:
    tinyformat.h: In instantiation of ‘static void tinyformat::detail::FormatArg::formatImpl(std::ostream&, const char*, const char*, int, const void*) [with T = void(); std::ostream = std::basic_ostream<char>]’:
    tinyformat.h:545:38:   required from ‘tinyformat::detail::FormatArg::FormatArg(const T&) [with T = void()]’
    tinyformat.h:1000:32:   required from ‘tinyformat::detail::FormatListN<N>::FormatListN(const Args& ...) [with Args = {void()}; int N = 1]’
    tinyformat.h:1053:20:   required from ‘tinyformat::detail::FormatListN<sizeof... (Args)> tinyformat::makeFormatList(const Args& ...) [with Args = {void()}]’
    tinyformat.h:1089:37:   required from ‘void tinyformat::format(std::ostream&, const char*, const Args& ...) [with Args = {void()}; std::ostream = std::basic_ostream<char>]’
    tinyformat.h:1098:11:   required from ‘std::string tinyformat::format(const char*, const Args& ...) [with Args = {void()}; std::string = std::basic_string<char>]’
    test_debugger4.cpp:9:54:   required from here
    tinyformat.h:568:57: error: invalid static_cast from type ‘const void*’ to type ‘void (*)()’
                 formatValue(out, fmtBegin, fmtEnd, ntrunc, *static_cast<const T*>(value));
                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tinyformat.h: In instantiation of ‘static int tinyformat::detail::FormatArg::toIntImpl(const void*) [with T = void()]’:
    tinyformat.h:545:38:   required from ‘tinyformat::detail::FormatArg::FormatArg(const T&) [with T = void()]’
    tinyformat.h:1000:32:   required from ‘tinyformat::detail::FormatListN<N>::FormatListN(const Args& ...) [with Args = {void()}; int N = 1]’
    tinyformat.h:1053:20:   required from ‘tinyformat::detail::FormatListN<sizeof... (Args)> tinyformat::makeFormatList(const Args& ...) [with Args = {void()}]’
    tinyformat.h:1089:37:   required from ‘void tinyformat::format(std::ostream&, const char*, const Args& ...) [with Args = {void()}; std::ostream = std::basic_ostream<char>]’
    tinyformat.h:1098:11:   required from ‘std::string tinyformat::format(const char*, const Args& ...) [with Args = {void()}; std::string = std::basic_string<char>]’
    test_debugger4.cpp:9:54:   required from here
    tinyformat.h:574:45: error: invalid static_cast from type ‘const void*’ to type ‘void (*)()’
                 return convertToInt<T>::invoke(*static_cast<const T*>(value));
                                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    opened by evandrocoan 1
  • Issues found during tinyformat audit (part of Bitcoin Core audit)

    Issues found during tinyformat audit (part of Bitcoin Core audit)

    Hi all,

    First, thanks for creating the tinyformat library. Having an easy-to-use locale independent formatting library available under a permissive license is really nice! :)

    Bitcoin Core uses tinyformat for formatting of log messages. While auditing Bitcoin Core I discovered the following issues in tinyformat that I thought were worth reporting upstreams.

    All issues have been verified against current master.

    Issue 1. The following causes a signed integer overflow and a subsequent allocation of 9 GB of RAM (or an OOM in memory constrained environments):

    tfm::format("%.777777700000000$", 1.0);
    

    Issue 2. The following causes a stack overflow:

    tfm::format("%987654321000000:", 1);
    

    Issue 3. The following causes a stack overflow:

    tfm::format("%1$*1$*", -11111111);
    

    Issue 4. The following causes a NULL pointer dereference:

    tfm::format("%.1s", (char *)nullptr);
    

    Issue 5. The following causes a float cast overflow:

    tfm::format("%c", -1000.0);
    

    Issue 6. The following causes a float cast overflow followed by an invalid integer negation:

    tfm::format("%*", std::numeric_limits<double>::lowest());
    

    Note that I've only audited tfm::format(…, …) which is the part of tinyformat used by Bitcoin Core.

    Thanks for a nice library!

    opened by practicalswift 5
Releases(v2.3.0)
  • v2.3.0(Nov 15, 2019)

    New features:

    • Support for %a and %A hexfloat format specs (https://github.com/c42f/tinyformat/pull/53)
    • Support for Posix positional arguments (https://github.com/c42f/tinyformat/pull/45)

    Bug fixes:

    • Fix UB in copying detail::FormatListN occurring in builds without copy constructor elision (https://github.com/c42f/tinyformat/pull/59)
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Apr 5, 2019)

    A few minor features and fixes:

    • TINYFORMAT_ASSERT macro for people wanting to avoid dependency on assert() and the <cassert> header
    • Fix GCC-7 Wimplicit-fallthrough warnings
    • Extra NULL initializations to silence spurious Coverty warnings
    • Various project improvements (CI + build; markdown docs)
    Source code(tar.gz)
    Source code(zip)
Owner
Chris Foster
Chris Foster
Group project: writing our own printf function

0x11. C - printf By Julien Barbier, co-founder & CEO Concepts For this project, students are expected to look at these concepts: Group Projects Pair P

Pericles ADJOVI 4 Aug 9, 2022
Writing our own printf function, this is a project done under ALX Low Level Programming.

0x11. C - printf Writing our own printf function, this is a project done under ALX Low Level Programming. Resource secrets of printf Implementing prin

Ephantus Mwangi 3 Apr 18, 2022
This is a simple example on how to have a working printf on stm32f4

STM32F4 - Printf This is a short example commented on how to use printf during stm32f4 development through UART. How to use ? This project use a STM32

Bastien Germond 1 Nov 4, 2021
SIDKick -- the first complete SID 6581/8580-drop-in-replacement that you can build yourself

.- the first complete SID-drop-in-replacement that you can build yourself -. SIDKick is a drop-in replacement for the SID sound chips used in C64s and

null 91 Sep 22, 2022
ByteCopy , or BCP, intends to copy files accurately (down to the bytes) in a simple , safe and efficient manner.

ByteCopy v3.6 About ByteCopy , or BCP, intends to copy files accurately (down to the bytes) in a simple , safe and efficient manner. It's functionalit

A.P. Jo. 16 Jun 22, 2022
A header only C++ library that provides type safety and user defined literals for physical units

SI - Type safety for physical units A header only c++ library that provides type safety and user defined literals for handling pyhsical values defined

Dominik Berner 386 Sep 28, 2022
This library support run-time type casting faster than dynamic_cast ( similar to unreal engine's CastTo )

Fast Runtime Type Casting This library give you C++ Fast Runtime Type Casting faster than dynamic_cast ( similar to Unreal Engine's CastTo, IsChildOf

SungJinKang 7 Jun 11, 2022
minimal msvc-windows exclusive lazy importer for C++

Lazy-Importer minimalistic msvc-windows exclusive lazy importer for C++20 (c++2a) Credits 0x90 (@AmJayden) @gogo9211 What is this? This lazy importer

Jayden 16 Sep 24, 2022
Isocline is a pure C library that can be used as an alternative to the GNU readline library

Isocline: a portable readline alternative. Isocline is a pure C library that can be used as an alternative to the GNU readline library (latest release

Daan 129 Sep 22, 2022
A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename.

whereami A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename. usag

Blackle Morisanchetto 3 Sep 24, 2022
Command-line arguments parsing library.

argparse argparse - A command line arguments parsing library in C (compatible with C++). Description This module is inspired by parse-options.c (git)

Yecheng Fu 512 Sep 26, 2022
A cross platform C99 library to get cpu features at runtime.

cpu_features A cross-platform C library to retrieve CPU features (such as available instructions) at runtime. Table of Contents Design Rationale Code

Google 2.1k Sep 25, 2022
Library that solves the exact cover problem using Dancing Links, also known as DLX.

The DLX Library The DLX library The DLX library solves instances of the exact cover problem, using Dancing Links (Knuth’s Algorithm X). Also included

Ben Lynn 41 Sep 30, 2022
Standards compliant, fast, secure markdown processing library in C

Hoedown Hoedown is a revived fork of Sundown, the Markdown parser based on the original code of the Upskirt library by Natacha Porté. Features Fully s

Hoedown 917 Sep 30, 2022
CommonMark parsing and rendering library and program in C

cmark cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. (For the JavaScript reference impl

CommonMark 1.4k Sep 27, 2022
A cross-platform protocol library to communicate with iOS devices

libimobiledevice A library to communicate with services on iOS devices using native protocols. Features libimobiledevice is a cross-platform software

libimobiledevice 5.2k Sep 26, 2022
Platform independent Near Field Communication (NFC) library

*- * Free/Libre Near Field Communication (NFC) library * * Libnfc historical contributors: * Copyright (C) 2009 Roel Verdult * Copyright (C) 2009

null 1.3k Sep 28, 2022
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.6k Oct 4, 2022
Your friendly e-mail address validation library.

libvldmail Your friendly e-mail address validation library. Why? Did you know that parentheses, spaces and - according to the RFC 6531 document - emoj

Cthulhux 46 Sep 9, 2022