[PATCH] printf: handle the L modifier for integers

[PATCH] printf: handle the L modifier for integers

[Andrei Vagin]

The L modifier is usually used for floating-point numbers, but
glibc allows to use this modifier for integers too.

I think here is nothing wrong if we will be compatible with glibc here.

It is not often when a error code of printf is checked, so we may have
a situation when a code works with glibc and doesn't work with musl.

Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
---
 src/stdio/vfprintf.c  | 3 +++
 src/stdio/vfwprintf.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/stdio/vfprintf.c b/src/stdio/vfprintf.c
index 50fb55c1..7f6c4f39 100644
--- a/src/stdio/vfprintf.c
+++ b/src/stdio/vfprintf.c
@@ -82,6 +82,9 @@ static const unsigned char states[]['z'-'A'+1] = {
 	}, { /* 5: L-prefixed */
 		S('e') = LDBL, S('f') = LDBL, S('g') = LDBL, S('a') = LDBL,
 		S('E') = LDBL, S('F') = LDBL, S('G') = LDBL, S('A') = LDBL,
+		S('d') = LLONG, S('i') = LLONG,
+		S('o') = ULLONG, S('u') = ULLONG,
+		S('x') = ULLONG, S('X') = ULLONG,
 		S('n') = PTR,
 	}, { /* 6: z- or t-prefixed (assumed to be same size) */
 		S('d') = PDIFF, S('i') = PDIFF,
diff --git a/src/stdio/vfwprintf.c b/src/stdio/vfwprintf.c
index e87ad42a..c6ce82ea 100644
--- a/src/stdio/vfwprintf.c
+++ b/src/stdio/vfwprintf.c
@@ -73,6 +73,9 @@ static const unsigned char states[]['z'-'A'+1] = {
 	}, { /* 5: L-prefixed */
 		S('e') = LDBL, S('f') = LDBL, S('g') = LDBL, S('a') = LDBL,
 		S('E') = LDBL, S('F') = LDBL, S('G') = LDBL, S('A') = LDBL,
+		S('d') = LLONG, S('i') = LLONG,
+		S('o') = ULLONG, S('u') = ULLONG,
+		S('x') = ULLONG, S('X') = ULLONG,
 		S('n') = PTR,
 	}, { /* 6: z- or t-prefixed (assumed to be same size) */
 		S('d') = PDIFF, S('i') = PDIFF,
-- 
2.14.3

Re: [PATCH] printf: handle the L modifier for integers

[Markus Wichmann]

On Fri, Jun 01, 2018 at 12:56:55AM +0300, Andrei Vagin wrote:
> The L modifier is usually used for floating-point numbers, but
> glibc allows to use this modifier for integers too.
> 

Nice for them. Looking forward to seeing how they deal with any possible
future standard definition of %Ld. Probably the same ugly way they deal
with signal() and scanf(), i.e. provide different #defines for them
based on feature flags.

> I think here is nothing wrong if we will be compatible with glibc here.
> 

Yes there is, and it was just explained: It breaks forward
compatibility.

> It is not often when a error code of printf is checked, so we may have
> a situation when a code works with glibc and doesn't work with musl.
> 

Correct solution is then to detect this abuse of the interface and to
crash. That is something the programmer can't ignore.

Code "working" with one implementation and not with another is a little
thing known as undefined behavior. Good programmers avoid it.

Ciao,
Markus