On Tue, 13 Sep 2011 23:10:08 +0200 Carl-Daniel Hailfinger firstname.lastname@example.org wrote:
Am 23.08.2011 17:12 schrieb Stefan Tauner:
compile tested with gcc 4.4.5 and clang 2.8
I agree with the idea and support it. However, I don't know how supportable this is on 16 bit platforms with 16 bit int.
jup, "int" is a bad choice for anything but trivial counters etc. imho.
We need at least 24 bits to handle flash addresses,
with hardware sequencing we need at least 25 bits (hwseq can address up to 2 flash chips seamlessly).
and we could either create a new typedef chipoffset_t or specify uint32_t explicitly. I favor a new typedef because it will make auditing easier if we ever run on 16 bit programmers.
introducing new types is certainly an option imo. but i think they should be used sparely and have good names (yes, a long discussing AGAIN :P). what about chip offset differences for example (i guess they are needed somewhere... and maybe even in a signed version)? in general i think the flash offset/address/size is the best candidate for a new type and i would be in favor of using typedef instead of other declarations of it (macros, oral/written human readable rules or whatever).
Signed-off-by: Stefan Tauner email@example.com
A comment about the typedef idea would be appreciated. Anyway, this is (even if you reject the explicit type idea) Acked-by: Carl-Daniel Hailfinger firstname.lastname@example.org
ok, thanks! i'll wait a few days before (rebasing and) committing, because it touches so much and someone may wanna postpone it for some reason... if you want it in sooner please say so (on IRC).