[poppler?] broken printf?

[tomty89]

I happened to discover that pdfunite produces glitched pdf files and thought that it was an upstream poppler issue:

https://bugs.freedesktop.org/show_bug.cgi?id=103873

But turns out the glitches are triggered by a printf that ONLY does not properly run on the Termux build:

void PDFDoc::writeHeader(OutStream *outStr, int major, int minor)
{
   outStr->printf("%%PDF-%d.%d\n", major, minor);
   outStr->printf("%%\xE2\xE3\xCF\xD3\n");
}

(https://cgit.freedesktop.org/poppler/poppler/tree/poppler/PDFDoc.cc)

$ strace pdfunite empty/003.pdf strace.pdf |& grep write.*PDF
write(4, "%PDF-1.3\n%", 10)             = 10
$ strace pdftocairo -pdf empty/003.pdf strace.pdf |& grep write.*PDF
write(4, "%PDF-1.5\n%\265\355\256\373\n3 0 obj\n<< /Lengt"..., 4096) = 4096
$ ./arch/startarch
[01:34 home ]$ strace pdfunite empty/003.pdf strace.pdf |& grep write.*PDF
write(4, "%PDF-1.3\n%\342\343\317\323\n4 0 obj <</Filter"..., 1756) = 1756
[01:34 home ]$ strace pdftocairo -pdf empty/003.pdf strace.pdf |& grep write.*PDF
write(4, "%PDF-1.5\n%\265\355\256\373\n4 0 obj\n<< /Lengt"..., 4096) = 4096

As you can see, with the Termux build the second printf stops after printing the literal %. The fact that it doesn't at least print the remaining \n makes the following line a comment, hence produces glitched files. (While the printf seems to always fail, not all glitched files makes pdfinfo spit errors.)

The pdftocairo trials are for reference. The job is done by cairo instead and it works fine with both builds:

...
	_cairo_output_stream_printf (surface->output,
				     "%%PDF-%s\n", version);
	_cairo_output_stream_printf (surface->output,
				     "%%%c%c%c%c\n", 181, 237, 174, 251);
...

(https://cgit.freedesktop.org/cairo/tree/src/cairo-pdf-surface.c)

So, has anyone got any idea on why the printf hiccups?

[enh]

prior to Android P (i.e. AOSP master), Android's printf didn't accept invalid UTF8 sequences in the format string, and so can't be used to print arbitrary bytes like this. you'd need to use %c%c%c%c -- as your other example does -- or (hilariously) %s (because only the format string is checked). this is from BSD code, so it's not just Android that has/had this limitation, so you may be able to get upstream to switch to the same %c%c%c%c workaround as your other example.

[fornwall]

Thanks a lot @tomty89 and @enh for the help!

An updated poppler package at version 0.61.1-2 is now available which contains the following patch: https://github.com/termux/termux-packages/blob/master/packages/poppler/poppler-PDFDoc.cc.patch

I also submitted the patch upstream at https://bugs.freedesktop.org/show_bug.cgi?id=103873.

[tomty89]

@enh That was what I have guessed thought it would be trickier (that it would be a bug that kicks in only in some occasions instead of a limitation). Can confirm everything you said with a simple program:

#include <stdio.h>

int main() {
  printf("%%\xE2\xE3\xCF\xD3\n");
  printf("%%%s\n", "\xE2\xE3\xCF\xD3");
  printf("%%%c%c%c%c\n", 0xe2, 0xe3, 0xcf, 0xd3);
}

Thank you for making it clear :-)

@fornwall Thank you for the effort :-)