Hi Simon,
On Tue, 16 Dec 2014 21:38:34 -0700 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 15 December 2014 at 18:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 15 December 2014 at 09:55, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.
I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Could you tell me which toolchain violates it?
Some compilers use 'unsigned long' and some use 'unsigned long long'. I think that is the core of the problem.
We don't have a problem with unsigned long long not being at least 64-bit. I wonder whether some toolchains use 128-bit for this?
That is not my point.
"unsigned long long" has 64-bit width whether on 32bit compilers or 64bit compilers or whatever.
I think that might be true at least for gcc. But in principle a 64-bit machine should use 128-bit for long long.
128-bit variable? Are you kidding?
I am not talking about "in principle" things, but talking about real compilers.
So, on which compiler do you have problems? For instance, please?
We should always hard-code the definition: typedef unsigned long long uint64_t;
That's all. We can always use "%llx" for printing uint64_t or u64. (and this is what U-boot (and Linux) had used until you broke the consistency.)
If we include <stdint.h>, you are right. It is the beginning of nightmare. Some compilers use "unsigned long" for uint64_t and some use "unsigned long long" for uint64_t.
What did it buy us?
You just introduced unreadability by using PRIu64 for printing 64bit width variables.
I have also hit this problem with m68k and one other compiler in U-Boot. Is it because these compilers are broken, or something else?
I guess you are mentioning "size_t" problem on m68k. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188121/focus=188932
If so, you are already confused.
"size_t" is another problem that should be discussed separetely.
Notice [1] uint32_t, int32_t, uint64_t, int64_t, uintptr_t are provided by <stdint.h> [2] PRIx32, PRIx64, PRId32, PRId64 etc. are provided by <inttypes.h> [3] size_t is provided by <stddef.h>
We are talking about [1] and [2].
And also notice [1] and [2] should be provided by the same compiler to work correctly.
[3] should not be mixed up with [1].
If you are interested in the topic about the conflict between "size_t" type and "%z", I can introduce you another thread.
But I am not showing that, in case this discussion goes wrong.
Best Regards Masahiro Yamada