[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWedqgvrSCfpmDFdM=ww-6+8v39sz+92CQaYHO4x5jNNQ@mail.gmail.com>
Date: Tue, 22 Jan 2013 23:26:16 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Stepan Moskovchenko <stepanm@...eaurora.org>
Cc: Rob Landley <rob@...dley.net>,
Andrew Morton <akpm@...ux-foundation.org>,
George Spelvin <linux@...izon.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Stephen Boyd <sboyd@...eaurora.org>,
Andrei Emeltchenko <andrei.emeltchenko@...el.com>,
mingo@...nel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
<stepanm@...eaurora.org> wrote:
> Add the %pa format specifier for printing a phys_addr_t
> type, since the physical address size on some platforms
> can vary based on build options, regardless of the native
> integer type.
I'm not so sure it's a good idea to start using %p for integer types.
For structures like MAC addresses, it makes life easier.
%p offers very minimal support from the compiler for checking the argument type.
At least with casting to "unsigned long long" and using %llu not much can go
wrong if there are no compiler warnings.
Also variables holding MAC address typically don't change, while there's been
lots of churn in variables changing type from unsigned long to phys_addr_t or
unsigned long long or void *. Without help of the compiler to catch
incorrect format
specifiers, it will become much more difficult to get and keep all of
them correct.
Just my two (euro)cents...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
Powered by blists - more mailing lists