Subtle difference between FreeBSD, MacOSX and Linux printf
by Wojciech Adam Koszek ⋅ Oct 28, 2015 ⋅ Menlo Park, CAThings you'll find when you try to write a substitute for one of the most basic and rudimentar pieces of UNIX C API. Treat it as "lessons learned" from implementing `mini_printf`.
I’m working on polishing my mini_printf
implementation and making a final, verified and documented code release, and the thing I made work in the past and something that stopped working when I moved to MacOSX was a randomized stress-test.
https://github.com/wkoszek/mini_printf
It’s pretty neat: it uses its own PRNG generator to achieve repeatability and uses its numbers to construct randomized format strings which are then played against OSes printf()
and my mini_printf()
API. Both versions are later compared. I exposed a lot of bugs in mini_printf
that way, of which all have been fixed.
So anyway: I refactored mini_printf
to the state where I can show it to other people. I also made the stress-test work on MacOSX, and I could play 1,000,000 random format string patterns with 0 failures in couple of seconds. But the same code failed miserably on Linux.
It looks like my stressing testbench found a usability problem between Linux and MacOSX printf. Problem shows up when you decide to use unsupported format string specifier. While Linux leaves the %
signs, MacOSX doesn’t propagate them to the string. I guess I’ll have to find a way to elegantly solve it, and preferably without any #defines
.
Program
wk:/w/repos/mini_printf> cat p.c
#include <stdio.h>
int
main()
{
printf("%k%k%k\n");
}
Linux
vagrant@vagrant-ubuntu-trusty-64:/vagrant/mini_printf$ ./p
%k%k%k
MacOSX and FreeBSD
wk:/w/repos/mini_printf> ./p
kkk