Re: [musl] [PATCH] [RFC] trap on invalid printf formats

["Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>]

Excerpts from Rich Felker's message of June 22, 2023 10:45 am:
> FWIW I don't think there are a lot of these cases left in the wild at
> all, but I'm not sure. it might be nice to do some distro-wide testing
> with this patch applied (which is what I had in mind posting it) and
> see if any problems are caught before really considering whether to
> pursue upstreaming it.

Unfortunately, it seems fairly widespread:
https://codesearch.debian.net/search?q=printf.*%5B%25%5DL%5Bud%5D+-package%3Agcc+-package%3Allvm*+path%3A.*%5C.c%24&literal=0

The most painful example:

#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__APPLE_CC__) || defined(__APPLE__) || defined(ARGUS_SOLARIS)
    sprintf (pbuf, "%llu", value);
#else
    sprintf (pbuf, "%Lu", value);
#endif

(copied and pasted 17 times in the same file, of course)

I did some research and the most likely source of %Lu is the Linux 
man-pages, which, before 1999 or thereabouts, said:

> • The optional character l (ell) specifying that a following d, i, o, 
> u, x, or X conversion applies to a pointer to a long int or unsigned 
> long int argument, or that a following n conversion corresponds to a 
> pointer to a long int argument.  Linux provides a non ANSI compliant 
> use of two l flags as a synonym to q or L.  Thus ll can be used in 
> combination with float conversions.  *This usage is, however, strongly 
> discouraged.*
>
> • The character L specifying that a following e, E, f, g, or G 
> conversion corresponds to a long double argument, or a following d, i, 
> o, u, x, or X conversion corresponds to a long long argument.  Note 
> that long long is not specified in ANSI C and therefore not portable 
> to all architectures.

Emphasis added. So, pre-C99, L was in fact the recommended modifier for 
long long.

Cheers,
Alex.