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

Simon Glass sjg at chromium.org
Wed Dec 17 05:38:34 CET 2014


Hi Masahiro,

On 15 December 2014 at 18:38, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
>
> 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.

I think that might be true at least for gcc. But in principle a 64-bit
machine should use 128-bit for long long.

>
>
> 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?

Regards,
Simon


More information about the U-Boot mailing list