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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1388507067.2259.24.camel@joe-AO722>
Date:	Tue, 31 Dec 2013 08:24:27 -0800
From:	Joe Perches <joe@...ches.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	akpm@...ux-foundation.org, geert@...ux-m68k.org, jkosina@...e.cz,
	viro@...iv.linux.org.uk, davem@...emloft.net,
	keescook@...omium.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib/vsprintf: add %pT[C012] format specifier

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/