input

% cat test.c
sprintf(buf, "%d%%", 10);

output

% ./qrintf-pp  < test.c
Use of uninitialized value in concatenation (.) or string at ./qrintf-pp line 83, <STDIN> line 1.
_qrintf_finalize(_qrintf_%(_qrintf_d(_qrintf_init(buf) , 10)));

As of now, we have a code that emulates the behavior of gcc -wrapper in case clang (or other compiler) is being used.

However the argument parsing logic of the emulation is horrible; it just strips -o target and assumes that the last argument is the name of the source file. It is evident that such approach will fail in certain cases, e.g. when -Wl, is used after specifying the source file, or, when more than one source files are used.

We need to implement a better option parser like the one found in ccache or dist-cc.

Was just glancing through the code and noticed this in qrintf.h, is it a mistake?
if (sizeof(unsigned long long) == sizeof(unsigned long long))

Hi,

This is issue is not an issue, but a question.

What is the reason of redefining sprintf/snprintf to _qp_sprintf/_qp_snprintf which are not defined?
Is it a bug or is it supposed to be so?

I bumped to this matter because I want to use qrintf for hotspots and keep using sprintf for "regular" cases where simplicity and clearness matters more then speed.

With this block in qrintf.h I'm getting "undefined symbol: _qp_snprintf" error in runtime.

#undef sprintf
#define sprintf(...) _qp_sprintf(__VA_ARGS__)
#undef snprintf
#define snprintf(...) _qp_snprintf(__VA_ARGS__)

input

% cat test.c
sprintf(buf, "%s", ",");

output

% ./qrintf-pp  < test.c
_qrintf_finalize(_qrintf_s(_qrintf_init(buf) , "))

Expected

_qrintf_finalize(_qrintf_s(_qrintf_init(buf), ","))

Hi,

When I try to use qrintf with cmake, I got following errors:

➜  cmake-build-debug git:(master) CC="/usr/local/bin/qrintf cc" cmake ..
-- The C compiler identification is GNU 8.1.0
-- Check for working C compiler: /usr/local/bin/qrintf
-- Check for working C compiler: /usr/local/bin/qrintf -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - failed
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done

As you can see, the cmake try to test the C compile features, but it failed.

How we integrate qrintf with cmake?

I'm not a fan of autotools, but can't work around using it in this case. I encountered several issues when integrating qrintf into our Varnish build:

Because qrintf.h is included very early in the compile process, a number of header files are pulled in before any chance of including config.h is allowed. This breaks packages that self-define C environment options like _GNU_SOURCE or _XOPEN_SOURCE or the like.

In my specific case, this was solved by hacking qrintf.h to include:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

fixes the issue. I would submit a PR, but I'm sure that someone has an autotools build where the relevant guard is _HAVE_CONFIG_H and the file is also named differently.

I ran into a couple of other problems related to autohell:

1. When qrintf-gcc is specified as the CC to use for configure, a number of header feature tests break. (A ffsl(3) test failed in jemalloc, for a specific case.) I worked around this by specifying CC as an argument to make.
2. CFLAGS are not passed to qrintf-gcc. This requires one to set relevant build options a la CC="qrintf-gcc -std=gnu99 -Werror -Wall" make.

All of these things would be more easily resolved if it was easier / safer to include qrintf in projects built using these "tools". (In the meantime, I've worked around these issues, so this is not a high priority issue or anything. I'd be happy to submit patches if you have better ideas than the hacky ones I made.)

Current implementation is not optimized in the sense that it performs range check for every character even in cases when the check can be omitted (https://github.com/kazuho/qrintf/blob/f8b1f7a9a480b7413d1426c0b824b7038e4d8372/misc/gen-qrintf.h.pl#L281 is a good example).

qrintf-gcc uses -no-integrated-cpp and -wrapper, options specific to GCC.

When I use the tools written by perl, which depends on many package of perl. It's so difficult to use.
Can you please rewrite the tools in other language like c?
Thanks.
--zsx

Would be nice to see explicitly with which open source licenses this code is compatible.