-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 <yamad...@jp.panasonic.com> wrote: > Hi Simon, > > > > On Mon, 22 Dec 2014 21:58:49 -0700 > Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
