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

[Simon Glass]

-Gabe, who no longer works in this group

(Also we have 4 threads going so I'm only going to reply to this one)

Hi Masahiro,

On 24 December 2014 at 01:41, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> 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>.
>
>

See below.

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

OK, my point was just that we don't have a problem with anything other
than 64-bit types at present on the platforms I use.

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

Right, and neither does U-Boot. We just need to support doing it to
allow other software to build against U-Boot. An example is Chrome OS
verified boot, but I'm sure there will be others, since stdint is a
standard function of C compilers now.

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

If we have code which uses #include <stdint.h> it cannot build against
U-Boot headers unless U-Boot is also stdint-friendly. This is because
of the difference between using 'long' and 'long long' on 64-bit. As I
mentioned there are only 26 places in U-Boot right now which use
64-bit ints with printf(), a total of 8 files that need changing. I'm
sure this will grow and I am keen to find a better solution. As I
said, perhaps the kernel solution is better.

It would be great if you could help find a better solution. But can we
please try to focus the discussion more on a better solution rather
than trying to expand this to 8/16/32-bit where I believe we
don't/won't have a problem.

Regards,
Simon