Am 17.07.2013 00:04 schrieb Carl-Daniel Hailfinger:
Am 15.07.2013 22:49 schrieb Stefan Tauner:
On Mon, 15 Jul 2013 10:20:29 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 10.07.2013 21:17 schrieb Stefan Tauner:
unsigned long is not the right type for manipulating pointer values. Since C99 there are suitable unsigned and signed types available, namely uintptr_t and intptr_t respectively.
Use them in physmap.c and its callers where applicable.
This patch also changes the display width of all address values in physmap.c to 16/8 hex characters depending on the actual size.
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
Why don't you use PRIxPTR_WIDTH everywhere including dummyflasher.c?
That's a bug AFAICS, thanks.
Put another way, is there a reason to use PRIxPTR_WIDTH at all?
IIRC the C99 standard says that PRIxPTR guarantees a canonical formatting. I'm guessing the canonical formatting means (for most platforms) that the printed pointers have constant width, i.e. the PRIxPTR_WIDTH specifier is superfluous. I would avoid that specifier unless shown a real-world case where PRIxPTR formatted pointers have variable length inside the same flashrom executable.
You have shown a real-world case: Linux. Thanks for checking this. In that light, PRIxPTR_WIDTH is essential.
Do we care that C99 doesn't guarantee a 0x prefix for printed addresses with PRIxPTR? Will that cause confusion?
The main point of it is to get nicely aligned/readable addresses that are padded to the right(tm) size, and yes I guess the guaranteed 0x prefix too (I can't remember TBH :).
AFAIK the 0x prefix is not guaranteed, and it may even be missing on Windows. Someone would have to test (preferably not in Wine).
In your test case, 0x was missing. Do we want to manually add a "0x" prefix or do we want to use the "#" modifier? If PRIxPTR is "p" or some variant of it, this might cause a problem because the "#" modifier is not listed as valid modifier for "p" in C99.
Once the PRIxPTR_WIDTH stuff is consistent (preferably removed everywhere), this is:
s/removed/included/
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel