Re: [REGRESSION PATCH V2] vsprintf: Change struct printf_spec.precision from s8 to s16

["Justin P. mattock" <justinmattock@gmail.com>]

On 04/14/2010 09:27 AM, Joe Perches wrote:
> Commit ef0658f3de484bf9b173639cd47544584e01efa5 changed precision
> from int to s8.
>
> There is existing kernel code that uses a larger precision.
>
> An example from the audit code:
> 	vsnprintf(...,..., " msg='%.1024s'", (char *)data);
> which overflows precision and truncates to nothing.
>
> Extending precision size fixes the audit system issue.
>
> Other changes:
>
> Change the size of the struct printf_spec.type from u16 to u8 so
> sizeof(struct printf_spec) stays as small as possible.
> Reorder the struct members so sizeof(struct printf_spec) remains 64 bits
> without alignment holes.
> Document the struct members a bit more.
>
> Original-patch-by: Eric Paris<eparis@redhat.com>
> Signed-off-by: Joe Perches<joe@perches.com>
> ---
>   lib/vsprintf.c |   10 +++++-----
>   1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 24112e5..7376b7c 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -408,12 +408,12 @@ enum format_type {
>   };
>
>   struct printf_spec {
> -	u16	type;
> -	s16	field_width;	/* width of output field */
> +	u8	type;		/* format_type enum */
>   	u8	flags;		/* flags to number() */
> -	u8	base;
> -	s8	precision;	/* # of digits/chars */
> -	u8	qualifier;
> +	u8	base;		/* number base, 8, 10 or 16 only */
> +	u8	qualifier;	/* number qualifier, one of 'hHlLtzZ' */
> +	s16	field_width;	/* width of output field */
> +	s16	precision;	/* # of digits/chars */
>   };
>
>   static char *number(char *buf, char *end, unsigned long long num,
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

just applied:
the first patch in this thread is good,
as well as this one.

Tested-by: Justin P. Mattock <justinmattock@gmail.com>

Justin P. Mattock