Re: [PATCH] lib/vsprintf: add %pT[C012] format specifier

From: Joe Perches
Date: Tue Dec 31 2013 - 11:24:40 EST

On Tue, 2013-12-31 at 15:53 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > Also I prefer using ASCII SUB (26 \x1a \032 ^z) or maybe
> > PU1 - 145 or PU2 - 146, as an initiator byte as it takes
> > up much less of the control word space instead of using
> > multiple values like \x80, \x81, \x82, etc. Using an
> > initiator byte seems more extensible too.
> My format and rules are:
> #define EMBED_FORMAT "0x7F"
> #define EMBED_CURRENT_COMM "0x80"
> #define EMBED_CURRENT_PID "0x81"
> We need to use EMBED_FORMAT prefix only when you want to specify one (or
> more) of flags, field width and precision options. That is,
> pr_info("%s(%d)\n", current->comm, current->pid);
> pr_info("[%-6.6s]\n", current->comm);
> => pr_info(EMBED_FORMAT "-6.6" EMBED_CURRENT_COMM "\n");
> But I can't imagine what your format and rules are because
> #define CURRENT_SUB "\032"
> #define CURRENT_SUB_ASCII '\032'
> are ' ' character which is also used within the format string.
> Also, if you assign one of ('0' to '9', '-', '.') for variable name like
> you will need a separating byte in order to distinguish end of
> flags, field width and precision options.

The goal of a single leading char is simply resource
economy. Using fewer chars from the available pool may be
better than using more. Using a couple more bytes in the
format string doesn't seem an excessive overhead.

> Please describe your format and rules (e.g. what byte starts a built-in token;
> what bytes are used for representing variable name, what separates flags, field
> width and precision options from variable name if these options are specified,
> what byte terminates a built-in token) using examples below.
> pr_info("%s(%d)\n", current->comm, current->pid);

pr_info(CURRENT_COMM "(" CURRENT_PID ")\n");

> pr_info("[%-6.6s]\n", current->comm);

I think using formatting controls for field widths and
such shouldn't be supported but if it is, then using yet
another macro form like below is possible

#define CURRENT_COMM_FORMAT(fmt) \
CURRENT_SUB __stringify(fmt) "2"

So maybe,
pr_info(CURRENT_COMM_FORMAT("-6.6") "\n");
pr_info(CURRENT_COMM_FORMATTED(-6.6) "\n");

depending on taste could work.

"2" would need changing to something like "t2" so any
leading format directives like field width and precision
could be done properly.

In other words: using a separating byte may be necessary if
some formatting directive support is required.

This wouldn't/couldn't work with formats where field length
is specified via "*" with a separate int.

Perhaps that's a good enough reason not to support using
format directives.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at