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

Masahiro YAMADA
2014-12-16T01:38:02Z

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.

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