[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Masahiro YAMADA]

Hi Simon,


2014-12-16 3:38 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Masahiro,
>
> On 15 December 2014 at 09:55, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
>> Hi Simon,
>>
>>
>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg at 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