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

[Joe Perches]

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(EMBED_CURRENT_COMM "(" EMBED_CURRENT_PID ")\n");
> 
>     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
> 
>   #define CURRENT_ID		CURRENT_SUB "1"
>   #define CURRENT_COMM		CURRENT_SUB "2"
> 
> 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

either:
#define CURRENT_COMM_FORMAT(fmt)		\
	CURRENT_SUB fmt "2"
or
#define CURRENT_COMM_FORMATTED(fmt)		\
	CURRENT_SUB __stringify(fmt) "2"

So maybe,
	pr_info(CURRENT_COMM_FORMAT("-6.6") "\n");
or
	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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/