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

[Masahiro Yamada]

Hi Simon,



On Tue, 16 Dec 2014 21:38:34 -0700
Simon Glass <sjg at chromium.org> wrote:

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

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