Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass <s...@chromium.org>: > Hi Masahiro, > > On 15 December 2014 at 09:55, Masahiro YAMADA <yamad...@jp.panasonic.com> > wrote: >> Hi Simon, >> >> >> 2014-10-15 19:38 GMT+09:00 Simon Glass <s...@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. 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. Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
