[U-Boot] [OpenQuestion] stdint.h and inttypes.h in U-Boot ?

[Masahiro Yamada]

Hi Simon,



On Mon, 22 Dec 2014 21:58:49 -0700
Simon Glass <sjg at chromium.org> wrote:


> >
> >
> >
> >> >
> >> >
> >> > Until commit 0d296cc2d, U-Boot has used the hard-coded defines like Linux.
> >>
> >> Well it still does, only that it also now has the *option* of using stdint.h.
> >
> > No.
> > It is not "Do not worry, it is optional" things.
> >
> > You have changed code here ard threr for the optional feature.
> >
> > Commit aac618a32 (ext4: Use inttypes for printf() string)
> > Commit 19ea4678c (Use int64_t for time types)
> > Commit 6bf672592 (Use uint64_t instead of u64 in put_dec())
> > Commit c6da9ae8a (Tidy up data sizes and function comment in display_options)
> >
> > etc.
> >
> >
> 
> These are all very small commits and only deal with 64-bit printf()s.
> It seems a small price to pay for the compatibility benefits of
> supporting stdint.h. The 32-bit madness is a red herring I think.

Why do you want to 64-bit types and printf()s only,
and leave 32-bit ones hard-coded ?

It is not clear to me.


> But anyway it seems like we can fix this problem so that stdint.h can
> be included without changing the types, as the kernel apparently does.

This statment implies your intention is *not* to change the typedefs.
If so, why do you want to include <stdint.h>?

Please explain your main motivation of including <stdint.h>.





> >
> >
> >> >
> >> > In my understaing, we should only use ILP32 and LP64 compilers.
> >> >
> >> >
> >> >                                  short   int      long    longlong    pointer
> >> > ILP32 (32bit system)               16    32       32        64         32
> >> > LP64  (64bit Unix-like system)     16    32       64        64         64
> >> >
> >> >
> >> > Whether it is 32bit or 64bit system, we can hard-code
> >> >
> >> >   u32/uint32_t    as  unsigned int
> >> >   u64/uint64_t    as  unsigned long long
> >> >   uintptr_t       as  unsigned long
> >> >
> >> > We do not need to refer to compiler-provided headers.
> >> >
> >> > Moreover, we  __should not__ refer to compiler-provided <stdint.h>.
> >> >
> >> >
> >> > Including <stdint.h> means that we use uint32_t defined by the compiler.
> >> > It is "unsigned int" on some compilers, and "unsigned long" on
> >> > some compilers.
> >>
> >> I don't seem to have that problem, or at least I have not noticed it
> >> with printf().
> >
> >
> > You are not trying to see the problem.  You should try.
> > Go to Linaro page and download the bare-metal toolchain.
> > http://www.linaro.org/downloads/
> 
> Fair enough, I do use Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013
> which doesn't seem to be broken in this way. Obviously I have just not
> tried enough compilers, although I did see the problem you describe on
> m68k.

Have you check my reply?
http://lists.denx.de/pipermail/u-boot/2014-December/199393.html

If you are mentioning size_t problem on m68k, it is also a red herring, I think.
It is another issue discussed separately.



> >> How do you explain stdint.h? So many projects use it - it is now part
> >> of the C99 standard. Has the world gone mad?
> >
> > It is trade-off and consistency things.
> >
> >
> > If you make a decision to use <stdint.h>, it must be consistent everywhere.
> >
> > <stdint.h> gives  int{8,16,32,64}_t and uint{8,16,32,64}_t, uintptr_t etc.
> >
> > We should always use them for fixed-width variable types
> > and should never use hard-coded ones.
> >
> > That means we should not use include/linux/types.h and friends
> > to hard-code u8/u16/u32/u64 etc.
> >
> > We always have to use PRIxN, PRIdN etc. to avoid printf-related warnings.
> > For that, compiler-provided <inttypes.h> must be included.
> >
> >
> > When you start a new project, you can include <stdint.h> and <inttypes.h>
> > and follow the that rule from the beginning.
> >
> >
> > You will see horrible things if you try to apply that rule on U-Boot.
> 
> I would like to find a solution to this. It does not seem like rocket
> science. If we accept that stdint.h is useful (I believe it is) then
> we can make it work perhaps as the kernel does. In other words, we can
> redefine the types (__INT32_TYPE__ etc.) instead of using the stdint.h
> ones. The effect is the same because it is not the bit widths that are
> different - it is just the type names.

I disagree about the statement "stdint.h is useful".

It is true the kernel includes <stdint.h> for ARM NEON
as Documentation/arm/kernel_mode_neon.txt,
but it is just one of a few exceptional cases.
The kernel never includes <stdint.h> in general use-cases.



> I'm not sure if that is what you are suggesting or not. But it seems
> like it should work, and avoid all the 64-bit PRI defines that you
> seem very upset about. There are only 26 uses in U-Boot as of now!

Even if there are only small number of uses, they are indeed ugly.

On both 32bit and 64bit compilers, "long long" has the 64bit width.
As Linux does,  we can hard-code the 64bit-types as "long long".

It it not clear to me why you want to change the typedefs of 64-bit types.



Please answer this question
- What kind problem do you have if 64bit-types are hard-coded.




Best Regards
Masahiro Yamada