[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2): Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8): ext4: Use inttypes for printf() string Use uint64_t for time types Use uint64_t instead of u64 in put_dec() Tidy up data sizes and function comment in display_options x86: Use correct printf() format string for uintptr_t scsi: Use correct printf() format string for uintptr_t usb: Use correct printf() format string for uintptr_t test: Add a simple test to detected warnings with uint64_t, uintptr_t
README | 5 + arch/sandbox/include/asm/types.h | 5 + arch/x86/include/asm/types.h | 5 + arch/x86/lib/relocate.c | 3 +- common/cmd_scsi.c | 9 +- common/usb_storage.c | 11 +- config.mk | 5 + fs/ext4/ext4_common.c | 3 +- include/common.h | 19 ++- include/compiler.h | 11 +- include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++ include/linux/types.h | 9 +- include/stdlib.h | 12 ++ lib/display_options.c | 14 +- lib/time.c | 12 +- lib/vsprintf.c | 2 +- test/stdint/int-types.c | 13 ++ test/stdint/test-includes.sh | 58 ++++++++ 18 files changed, 450 insertions(+), 33 deletions(-) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh

From: Gabe Black gabeblack@chromium.org
There's a definition in stdint.h (provided by gcc) which will be more correct if available.
Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make' commmand.
This adjusts the settings for x86 and sandbox, with both have 64-bit options.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Rewritten to be an option, since stdint.h is often available only in glibc. Changed to preserve a clear boundary between stdint and non-stdint Signed-off-by: Simon Glass sjg@chromium.org
---
README | 5 +++++ arch/sandbox/include/asm/types.h | 5 +++++ arch/x86/include/asm/types.h | 5 +++++ config.mk | 5 +++++ include/compiler.h | 11 ++++++++--- include/linux/types.h | 9 ++++++++- 6 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/README b/README index 6ecb3e0..72e8db9 100644 --- a/README +++ b/README @@ -4055,6 +4055,11 @@ Configuration Settings: be asserted. See doc/README.omap-reset-time for details on how the value can be calulated on a given board.
+- CONFIG_USE_STDINT + If stdint.h is available with your toolchain you can define this + option to enable it. You can provide option 'USE_STDINT=1' when + building U-Boot to enable this. + The following definitions that deal with the placement and management of environment data (variable area); in general, we support the following configurations: diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h index 6d3eb1f..42c09e2 100644 --- a/arch/sandbox/include/asm/types.h +++ b/arch/sandbox/include/asm/types.h @@ -42,8 +42,13 @@ typedef unsigned short u16; typedef signed int s32; typedef unsigned int u32;
+#if !defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__) typedef signed long long s64; typedef unsigned long long u64; +#else +typedef __INT64_TYPE__ s64; +typedef __UINT64_TYPE__ u64; +#endif
#define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG
diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h index e9fde88..e272c90 100644 --- a/arch/x86/include/asm/types.h +++ b/arch/x86/include/asm/types.h @@ -36,8 +36,13 @@ typedef unsigned short u16; typedef signed int s32; typedef unsigned int u32;
+#if !defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__) typedef signed long long s64; typedef unsigned long long u64; +#else +typedef __INT64_TYPE__ s64; +typedef __UINT64_TYPE__ u64; +#endif
#define BITS_PER_LONG 32
diff --git a/config.mk b/config.mk index 2157537..1ddfdbb 100644 --- a/config.mk +++ b/config.mk @@ -57,6 +57,11 @@ ifdef FTRACE PLATFORM_CPPFLAGS += -finstrument-functions -DFTRACE endif
+# Allow use of stdint.h if available +ifneq ($(USE_STDINT),) +PLATFORM_CPPFLAGS += -DCONFIG_USE_STDINT +endif + #########################################################################
RELFLAGS := $(PLATFORM_RELFLAGS) diff --git a/include/compiler.h b/include/compiler.h index 2103602..47c296e 100644 --- a/include/compiler.h +++ b/include/compiler.h @@ -112,6 +112,14 @@ typedef unsigned int uint;
#else /* !USE_HOSTCC */
+#ifdef CONFIG_USE_STDINT +/* Provided by gcc. */ +#include <stdint.h> +#else +/* Type for `void *' pointers. */ +typedef unsigned long int uintptr_t; +#endif + #include <linux/string.h> #include <linux/types.h> #include <asm/byteorder.h> @@ -128,9 +136,6 @@ typedef unsigned int uint; #define __WORDSIZE 32 #endif
-/* Type for `void *' pointers. */ -typedef unsigned long int uintptr_t; - #endif /* USE_HOSTCC */
#define likely(x) __builtin_expect(!!(x), 1) diff --git a/include/linux/types.h b/include/linux/types.h index 9aebc4e..c9a8d9a 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -104,7 +104,8 @@ typedef __u8 uint8_t; typedef __u16 uint16_t; typedef __u32 uint32_t;
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__) +#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && \ + (!defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__)) typedef __u64 uint64_t; typedef __u64 u_int64_t; typedef __s64 int64_t; @@ -112,6 +113,12 @@ typedef __s64 int64_t;
#endif /* __KERNEL_STRICT_NAMES */
+#if defined(CONFIG_USE_STDINT) && defined(__INT64_TYPE__) +typedef __UINT64_TYPE__ uint64_t; +typedef __UINT64_TYPE__ u_int64_t; +typedef __INT64_TYPE__ int64_t; +#endif + /* * Below are truly Linux-specific types that should never collide with * any application/library that wants linux/types.h.

On Wed, Oct 15, 2014 at 04:38:30AM -0600, Simon Glass wrote:
From: Gabe Black gabeblack@chromium.org
There's a definition in stdint.h (provided by gcc) which will be more correct if available.
Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make' commmand.
This adjusts the settings for x86 and sandbox, with both have 64-bit options.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Rewritten to be an option, since stdint.h is often available only in glibc. Changed to preserve a clear boundary between stdint and non-stdint Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
---
include/common.h | 3 + include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/stdlib.h | 12 +++ 3 files changed, 302 insertions(+) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h
diff --git a/include/common.h b/include/common.h index d5020c8..d8584dd 100644 --- a/include/common.h +++ b/include/common.h @@ -86,6 +86,9 @@ typedef volatile unsigned char vu_char; #include <flash.h> #include <image.h>
+/* Bring in printf format macros if inttypes.h is included */ +#define __STDC_FORMAT_MACROS + #ifdef __LP64__ #define CONFIG_SYS_SUPPORT_64BIT_DATA #endif diff --git a/include/inttypes.h b/include/inttypes.h new file mode 100644 index 0000000..e2e569d --- /dev/null +++ b/include/inttypes.h @@ -0,0 +1,287 @@ +/* + * Copyright (C) 1997-2001, 2004, 2007 Free Software Foundation, Inc. + * + * This file is taken from the GNU C Library v2.15, with the unimplemented + * functions removed and a few style fixes. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +/* + * ISO C99: 7.8 Format conversion of integer types <inttypes.h> + */ + +#ifndef _INTTYPES_H +#define _INTTYPES_H 1 + +#include <linux/compiler.h> + +/* Get a definition for wchar_t. But we must not define wchar_t itself. */ +#ifndef ____gwchar_t_defined +# ifdef __cplusplus +# define __gwchar_t wchar_t +# elif defined __WCHAR_TYPE__ +typedef __WCHAR_TYPE__ __gwchar_t; +# else +# define __need_wchar_t +# include <stddef.h> +typedef wchar_t __gwchar_t; +# endif +# define ____gwchar_t_defined 1 +#endif + + +/* The ISO C99 standard specifies that these macros must only be + defined if explicitly requested. */ +#if !defined __cplusplus || defined __STDC_FORMAT_MACROS + +#ifdef CONFIG_USE_STDINT +# if __WORDSIZE == 64 +# define __PRI64_PREFIX "l" +# define __PRIPTR_PREFIX "l" +# else +# define __PRI64_PREFIX "ll" +# define __PRIPTR_PREFIX +# endif +#else +/* linux/types.h always uses long long for 64-bit and long for uintptr_t */ +# define __PRI64_PREFIX "ll" +# define __PRIPTR_PREFIX "l" +#endif + +/* Macros for printing format specifiers. */ + +/* Decimal notation. */ +# define PRId8 "d" +# define PRId16 "d" +# define PRId32 "d" +# define PRId64 __PRI64_PREFIX "d" + +# define PRIdLEAST8 "d" +# define PRIdLEAST16 "d" +# define PRIdLEAST32 "d" +# define PRIdLEAST64 __PRI64_PREFIX "d" + +# define PRIdFAST8 "d" +# define PRIdFAST16 __PRIPTR_PREFIX "d" +# define PRIdFAST32 __PRIPTR_PREFIX "d" +# define PRIdFAST64 __PRI64_PREFIX "d" + + +# define PRIi8 "i" +# define PRIi16 "i" +# define PRIi32 "i" +# define PRIi64 __PRI64_PREFIX "i" + +# define PRIiLEAST8 "i" +# define PRIiLEAST16 "i" +# define PRIiLEAST32 "i" +# define PRIiLEAST64 __PRI64_PREFIX "i" + +# define PRIiFAST8 "i" +# define PRIiFAST16 __PRIPTR_PREFIX "i" +# define PRIiFAST32 __PRIPTR_PREFIX "i" +# define PRIiFAST64 __PRI64_PREFIX "i" + +/* Octal notation. */ +# define PRIo8 "o" +# define PRIo16 "o" +# define PRIo32 "o" +# define PRIo64 __PRI64_PREFIX "o" + +# define PRIoLEAST8 "o" +# define PRIoLEAST16 "o" +# define PRIoLEAST32 "o" +# define PRIoLEAST64 __PRI64_PREFIX "o" + +# define PRIoFAST8 "o" +# define PRIoFAST16 __PRIPTR_PREFIX "o" +# define PRIoFAST32 __PRIPTR_PREFIX "o" +# define PRIoFAST64 __PRI64_PREFIX "o" + +/* Unsigned integers. */ +# define PRIu8 "u" +# define PRIu16 "u" +# define PRIu32 "u" +# define PRIu64 __PRI64_PREFIX "u" + +# define PRIuLEAST8 "u" +# define PRIuLEAST16 "u" +# define PRIuLEAST32 "u" +# define PRIuLEAST64 __PRI64_PREFIX "u" + +# define PRIuFAST8 "u" +# define PRIuFAST16 __PRIPTR_PREFIX "u" +# define PRIuFAST32 __PRIPTR_PREFIX "u" +# define PRIuFAST64 __PRI64_PREFIX "u" + +/* lowercase hexadecimal notation. */ +# define PRIx8 "x" +# define PRIx16 "x" +# define PRIx32 "x" +# define PRIx64 __PRI64_PREFIX "x" + +# define PRIxLEAST8 "x" +# define PRIxLEAST16 "x" +# define PRIxLEAST32 "x" +# define PRIxLEAST64 __PRI64_PREFIX "x" + +# define PRIxFAST8 "x" +# define PRIxFAST16 __PRIPTR_PREFIX "x" +# define PRIxFAST32 __PRIPTR_PREFIX "x" +# define PRIxFAST64 __PRI64_PREFIX "x" + +/* UPPERCASE hexadecimal notation. */ +# define PRIX8 "X" +# define PRIX16 "X" +# define PRIX32 "X" +# define PRIX64 __PRI64_PREFIX "X" + +# define PRIXLEAST8 "X" +# define PRIXLEAST16 "X" +# define PRIXLEAST32 "X" +# define PRIXLEAST64 __PRI64_PREFIX "X" + +# define PRIXFAST8 "X" +# define PRIXFAST16 __PRIPTR_PREFIX "X" +# define PRIXFAST32 __PRIPTR_PREFIX "X" +# define PRIXFAST64 __PRI64_PREFIX "X" + + +/* Macros for printing `intmax_t' and `uintmax_t'. */ +# define PRIdMAX __PRI64_PREFIX "d" +# define PRIiMAX __PRI64_PREFIX "i" +# define PRIoMAX __PRI64_PREFIX "o" +# define PRIuMAX __PRI64_PREFIX "u" +# define PRIxMAX __PRI64_PREFIX "x" +# define PRIXMAX __PRI64_PREFIX "X" + + +/* Macros for printing `intptr_t' and `uintptr_t'. */ +# define PRIdPTR __PRIPTR_PREFIX "d" +# define PRIiPTR __PRIPTR_PREFIX "i" +# define PRIoPTR __PRIPTR_PREFIX "o" +# define PRIuPTR __PRIPTR_PREFIX "u" +# define PRIxPTR __PRIPTR_PREFIX "x" +# define PRIXPTR __PRIPTR_PREFIX "X" + + +/* Macros for scanning format specifiers. */ + +/* Signed decimal notation. */ +# define SCNd8 "hhd" +# define SCNd16 "hd" +# define SCNd32 "d" +# define SCNd64 __PRI64_PREFIX "d" + +# define SCNdLEAST8 "hhd" +# define SCNdLEAST16 "hd" +# define SCNdLEAST32 "d" +# define SCNdLEAST64 __PRI64_PREFIX "d" + +# define SCNdFAST8 "hhd" +# define SCNdFAST16 __PRIPTR_PREFIX "d" +# define SCNdFAST32 __PRIPTR_PREFIX "d" +# define SCNdFAST64 __PRI64_PREFIX "d" + +/* Signed decimal notation. */ +# define SCNi8 "hhi" +# define SCNi16 "hi" +# define SCNi32 "i" +# define SCNi64 __PRI64_PREFIX "i" + +# define SCNiLEAST8 "hhi" +# define SCNiLEAST16 "hi" +# define SCNiLEAST32 "i" +# define SCNiLEAST64 __PRI64_PREFIX "i" + +# define SCNiFAST8 "hhi" +# define SCNiFAST16 __PRIPTR_PREFIX "i" +# define SCNiFAST32 __PRIPTR_PREFIX "i" +# define SCNiFAST64 __PRI64_PREFIX "i" + +/* Unsigned decimal notation. */ +# define SCNu8 "hhu" +# define SCNu16 "hu" +# define SCNu32 "u" +# define SCNu64 __PRI64_PREFIX "u" + +# define SCNuLEAST8 "hhu" +# define SCNuLEAST16 "hu" +# define SCNuLEAST32 "u" +# define SCNuLEAST64 __PRI64_PREFIX "u" + +# define SCNuFAST8 "hhu" +# define SCNuFAST16 __PRIPTR_PREFIX "u" +# define SCNuFAST32 __PRIPTR_PREFIX "u" +# define SCNuFAST64 __PRI64_PREFIX "u" + +/* Octal notation. */ +# define SCNo8 "hho" +# define SCNo16 "ho" +# define SCNo32 "o" +# define SCNo64 __PRI64_PREFIX "o" + +# define SCNoLEAST8 "hho" +# define SCNoLEAST16 "ho" +# define SCNoLEAST32 "o" +# define SCNoLEAST64 __PRI64_PREFIX "o" + +# define SCNoFAST8 "hho" +# define SCNoFAST16 __PRIPTR_PREFIX "o" +# define SCNoFAST32 __PRIPTR_PREFIX "o" +# define SCNoFAST64 __PRI64_PREFIX "o" + +/* Hexadecimal notation. */ +# define SCNx8 "hhx" +# define SCNx16 "hx" +# define SCNx32 "x" +# define SCNx64 __PRI64_PREFIX "x" + +# define SCNxLEAST8 "hhx" +# define SCNxLEAST16 "hx" +# define SCNxLEAST32 "x" +# define SCNxLEAST64 __PRI64_PREFIX "x" + +# define SCNxFAST8 "hhx" +# define SCNxFAST16 __PRIPTR_PREFIX "x" +# define SCNxFAST32 __PRIPTR_PREFIX "x" +# define SCNxFAST64 __PRI64_PREFIX "x" + + +/* Macros for scanning `intmax_t' and `uintmax_t'. */ +# define SCNdMAX __PRI64_PREFIX "d" +# define SCNiMAX __PRI64_PREFIX "i" +# define SCNoMAX __PRI64_PREFIX "o" +# define SCNuMAX __PRI64_PREFIX "u" +# define SCNxMAX __PRI64_PREFIX "x" + +/* Macros for scaning `intptr_t' and `uintptr_t'. */ +# define SCNdPTR __PRIPTR_PREFIX "d" +# define SCNiPTR __PRIPTR_PREFIX "i" +# define SCNoPTR __PRIPTR_PREFIX "o" +# define SCNuPTR __PRIPTR_PREFIX "u" +# define SCNxPTR __PRIPTR_PREFIX "x" + +#endif /* C++ && format macros */ + + +#if __WORDSIZE == 64 + +/* We have to define the `uintmax_t' type using `ldiv_t'. */ +typedef struct { + long int quot; /* Quotient. */ + long int rem; /* Remainder. */ +} imaxdiv_t; + +#else + +/* We have to define the `uintmax_t' type using `lldiv_t'. */ +typedef struct { + long long int quot; /* Quotient. */ + long long int rem; /* Remainder. */ +} imaxdiv_t; + +#endif + +#endif /* inttypes.h */ diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/* + * Copyright (C) 2013 Google Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */

On Wed, Oct 15, 2014 at 04:38:31AM -0600, Simon Glass wrote:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
Applied to u-boot/master, thanks!

Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?

Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
Regards, Simon

Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.

Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
Regards, Simon

Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Regards, Jeroen

Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
From: Gabe Black gabeblack@chromium.org
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
Signed-off-by: Gabe Black gabeblack@google.com Reviewed-by: Gabe Black gabeblack@chromium.org Tested-by: Gabe Black gabeblack@chromium.org Reviewed-by: Bill Richardson wfrichar@google.com Signed-off-by: Simon Glass sjg@chromium.org (Replaced with a GPL version from glibc)
[snip]
diff --git a/include/stdlib.h b/include/stdlib.h new file mode 100644 index 0000000..6bc7fbb --- /dev/null +++ b/include/stdlib.h @@ -0,0 +1,12 @@ +/*
- Copyright (C) 2013 Google Inc.
- SPDX-License-Identifier: GPL-2.0+
- */
+#ifndef __STDLIB_H_ +#define __STDLIB_H_
+#include <malloc.h>
+#endif /* __STDLIB_H_ */
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Regards, Simon

Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org: > > From: Gabe Black gabeblack@chromium.org > > inttypes.h defines format specifiers for printf which work with data > types of > particular sizes. stdlib.h is currently just a passthrough to malloc.h > which > has declarations of the various *alloc functions. > > Add the required #define to common.h so that these printf format > specifiers > will be made available. > > Signed-off-by: Gabe Black gabeblack@google.com > Reviewed-by: Gabe Black gabeblack@chromium.org > Tested-by: Gabe Black gabeblack@chromium.org > Reviewed-by: Bill Richardson wfrichar@google.com > Signed-off-by: Simon Glass sjg@chromium.org > (Replaced with a GPL version from glibc) > [snip] > > diff --git a/include/stdlib.h b/include/stdlib.h > new file mode 100644 > index 0000000..6bc7fbb > --- /dev/null > +++ b/include/stdlib.h > @@ -0,0 +1,12 @@ > +/* > + * Copyright (C) 2013 Google Inc. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef __STDLIB_H_ > +#define __STDLIB_H_ > + > +#include <malloc.h> > + > +#endif /* __STDLIB_H_ */ > -- > 2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Sorry, I still don't get it. Could you explain user cases?

Hi Masahiro,
On 29 October 2014 08:06, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote: > > Hi Gabe, Simon, > > > 2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org: >> >> From: Gabe Black gabeblack@chromium.org >> >> inttypes.h defines format specifiers for printf which work with data >> types of >> particular sizes. stdlib.h is currently just a passthrough to malloc.h >> which >> has declarations of the various *alloc functions. >> >> Add the required #define to common.h so that these printf format >> specifiers >> will be made available. >> >> Signed-off-by: Gabe Black gabeblack@google.com >> Reviewed-by: Gabe Black gabeblack@chromium.org >> Tested-by: Gabe Black gabeblack@chromium.org >> Reviewed-by: Bill Richardson wfrichar@google.com >> Signed-off-by: Simon Glass sjg@chromium.org >> (Replaced with a GPL version from glibc) >> > [snip] >> >> diff --git a/include/stdlib.h b/include/stdlib.h >> new file mode 100644 >> index 0000000..6bc7fbb >> --- /dev/null >> +++ b/include/stdlib.h >> @@ -0,0 +1,12 @@ >> +/* >> + * Copyright (C) 2013 Google Inc. >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ >> + >> +#ifndef __STDLIB_H_ >> +#define __STDLIB_H_ >> + >> +#include <malloc.h> >> + >> +#endif /* __STDLIB_H_ */ >> -- >> 2.1.0.rc2.206.gedb03e5 > > > This patch is not clear to me. > > Why do we need include/stdlib.h ?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Sorry, I still don't get it. Could you explain user cases?
If you have a C file which has '#include <stdlib.h> in it, because it builds in another project as well as U-Boot, and needs mallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
Regards, Simon

Hi Simon,
On Wed, 29 Oct 2014 19:43:26 -0600 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 29 October 2014 08:06, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org: > > Hi Masahiro, > > On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com > wrote: >> >> Hi Gabe, Simon, >> >> >> 2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org: >>> >>> From: Gabe Black gabeblack@chromium.org >>> >>> inttypes.h defines format specifiers for printf which work with data >>> types of >>> particular sizes. stdlib.h is currently just a passthrough to malloc.h >>> which >>> has declarations of the various *alloc functions. >>> >>> Add the required #define to common.h so that these printf format >>> specifiers >>> will be made available. >>> >>> Signed-off-by: Gabe Black gabeblack@google.com >>> Reviewed-by: Gabe Black gabeblack@chromium.org >>> Tested-by: Gabe Black gabeblack@chromium.org >>> Reviewed-by: Bill Richardson wfrichar@google.com >>> Signed-off-by: Simon Glass sjg@chromium.org >>> (Replaced with a GPL version from glibc) >>> >> [snip] >>> >>> diff --git a/include/stdlib.h b/include/stdlib.h >>> new file mode 100644 >>> index 0000000..6bc7fbb >>> --- /dev/null >>> +++ b/include/stdlib.h >>> @@ -0,0 +1,12 @@ >>> +/* >>> + * Copyright (C) 2013 Google Inc. >>> + * >>> + * SPDX-License-Identifier: GPL-2.0+ >>> + */ >>> + >>> +#ifndef __STDLIB_H_ >>> +#define __STDLIB_H_ >>> + >>> +#include <malloc.h> >>> + >>> +#endif /* __STDLIB_H_ */ >>> -- >>> 2.1.0.rc2.206.gedb03e5 >> >> >> This patch is not clear to me. >> >> Why do we need include/stdlib.h ? > > This makes the U-Boot environment more similar to that used by other > software, so we can more easily build it without lots of glue files. > Normally stdlib.h defines malloc() and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Sorry, I still don't get it. Could you explain user cases?
If you have a C file which has '#include <stdlib.h> in it, because it builds in another project as well as U-Boot, and needs mallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
I understand what you want to do, but I am not sure if this is a right decision.
Mixing the same header name sometimes causes a mess.
Best Regards Masahiro Yamada

Hi Masahiro,
On 30 October 2014 01:53, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
On Wed, 29 Oct 2014 19:43:26 -0600 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 29 October 2014 08:06, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello Simon,
On 28-10-14 18:33, Simon Glass wrote:
Hi Masahiro,
On 28 October 2014 10:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote: > > Hi Simon, > > > 2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org: >> >> Hi Masahiro, >> >> On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com >> wrote: >>> >>> Hi Gabe, Simon, >>> >>> >>> 2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org: >>>> >>>> From: Gabe Black gabeblack@chromium.org >>>> >>>> inttypes.h defines format specifiers for printf which work with data >>>> types of >>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h >>>> which >>>> has declarations of the various *alloc functions. >>>> >>>> Add the required #define to common.h so that these printf format >>>> specifiers >>>> will be made available. >>>> >>>> Signed-off-by: Gabe Black gabeblack@google.com >>>> Reviewed-by: Gabe Black gabeblack@chromium.org >>>> Tested-by: Gabe Black gabeblack@chromium.org >>>> Reviewed-by: Bill Richardson wfrichar@google.com >>>> Signed-off-by: Simon Glass sjg@chromium.org >>>> (Replaced with a GPL version from glibc) >>>> >>> [snip] >>>> >>>> diff --git a/include/stdlib.h b/include/stdlib.h >>>> new file mode 100644 >>>> index 0000000..6bc7fbb >>>> --- /dev/null >>>> +++ b/include/stdlib.h >>>> @@ -0,0 +1,12 @@ >>>> +/* >>>> + * Copyright (C) 2013 Google Inc. >>>> + * >>>> + * SPDX-License-Identifier: GPL-2.0+ >>>> + */ >>>> + >>>> +#ifndef __STDLIB_H_ >>>> +#define __STDLIB_H_ >>>> + >>>> +#include <malloc.h> >>>> + >>>> +#endif /* __STDLIB_H_ */ >>>> -- >>>> 2.1.0.rc2.206.gedb03e5 >>> >>> >>> This patch is not clear to me. >>> >>> Why do we need include/stdlib.h ? >> >> This makes the U-Boot environment more similar to that used by other >> software, so we can more easily build it without lots of glue files. >> Normally stdlib.h defines malloc() and friends. > > I am not happy about this. > > Our right direction is to make U-Boot environment more similar to the > Kernel, I think. > > stdlib.h shouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Sorry, I still don't get it. Could you explain user cases?
If you have a C file which has '#include <stdlib.h> in it, because it builds in another project as well as U-Boot, and needs mallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
I understand what you want to do, but I am not sure if this is a right decision.
Mixing the same header name sometimes causes a mess.
That's true although I don't really see a big issue here.
IMO image.c and the like suffer from having two sets of headers - one for building in U-Boot and one for building outside. I thought maybe the solution was do have a section in common.h to deal with the differences, but then when I looked more I wasn't sure it was an improvement...
Regards, Simon

On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather than 'long long'. Use the inttypes header to avoid compiler warnings.
Signed-off-by: Simon Glass sjg@chromium.org ---
fs/ext4/ext4_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c index 33d69c9..cccc06a 100644 --- a/fs/ext4/ext4_common.c +++ b/fs/ext4/ext4_common.c @@ -22,6 +22,7 @@ #include <common.h> #include <ext_common.h> #include <ext4fs.h> +#include <inttypes.h> #include <malloc.h> #include <stddef.h> #include <linux/stat.h> @@ -73,7 +74,7 @@ void put_ext4(uint64_t off, void *buf, uint32_t size) if ((startblock + (size >> log2blksz)) > (part_offset + fs->total_sect)) { printf("part_offset is " LBAFU "\n", part_offset); - printf("total_sector is %llu\n", fs->total_sect); + printf("total_sector is %" PRIu64 "\n", fs->total_sect); printf("error: overflow occurs\n"); return; }

On Wed, Oct 15, 2014 at 04:38:32AM -0600, Simon Glass wrote:
On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather than 'long long'. Use the inttypes header to avoid compiler warnings.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

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.
Signed-off-by: Simon Glass sjg@chromium.org ---
include/common.h | 2 +- lib/time.c | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/common.h b/include/common.h index d8584dd..02befa6 100644 --- a/include/common.h +++ b/include/common.h @@ -776,7 +776,7 @@ void invalidate_dcache_all(void); void invalidate_icache_all(void);
/* arch/$(ARCH)/lib/ticks.S */ -unsigned long long get_ticks(void); +uint64_t get_ticks(void); void wait_ticks (unsigned long);
/* arch/$(ARCH)/lib/time.c */ diff --git a/lib/time.c b/lib/time.c index c7b0264..fe43ccb 100644 --- a/lib/time.c +++ b/lib/time.c @@ -41,7 +41,7 @@ unsigned long notrace timer_read_counter(void) extern unsigned long __weak timer_read_counter(void); #endif
-unsigned long long __weak notrace get_ticks(void) +uint64_t __weak notrace get_ticks(void) { unsigned long now = timer_read_counter();
@@ -49,11 +49,11 @@ unsigned long long __weak notrace get_ticks(void) if (now < gd->timebase_l) gd->timebase_h++; gd->timebase_l = now; - return ((unsigned long long)gd->timebase_h << 32) | gd->timebase_l; + return ((uint64_t)gd->timebase_h << 32) | gd->timebase_l; }
/* Returns time in milliseconds */ -static unsigned long long notrace tick_to_time(unsigned long long tick) +static uint64_t notrace tick_to_time(uint64_t tick) { ulong div = get_tbclk();
@@ -78,9 +78,9 @@ unsigned long __weak notrace timer_get_us(void) return tick_to_time(get_ticks() * 1000); }
-static unsigned long long usec_to_tick(unsigned long usec) +static uint64_t usec_to_tick(unsigned long usec) { - unsigned long long tick = usec; + uint64_t tick = usec; tick *= get_tbclk(); do_div(tick, 1000000); return tick; @@ -88,7 +88,7 @@ static unsigned long long usec_to_tick(unsigned long usec)
void __weak __udelay(unsigned long usec) { - unsigned long long tmp; + uint64_t tmp;
tmp = get_ticks() + usec_to_tick(usec); /* get current timestamp */

On Wed, Oct 15, 2014 at 04:38:33AM -0600, Simon Glass wrote:
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.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@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?

Hi Masahiro,
On 15 December 2014 at 09:55, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@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?
Regards, Simon

Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 15 December 2014 at 09:55, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@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.
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.
Best Regards Masahiro Yamada

Hi Masahiro,
On 15 December 2014 at 18:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 15 December 2014 at 09:55, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@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

Hi Simon,
On Tue, 16 Dec 2014 21:38:34 -0700 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 15 December 2014 at 18:38, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 15 December 2014 at 09:55, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass sjg@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

Use the correct type required by do_div().
Signed-off-by: Simon Glass sjg@chromium.org ---
lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 7ec758e..b585713 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -270,7 +270,7 @@ static char *put_dec_full(char *buf, unsigned q) return buf; } /* No inlining helps gcc to use registers better */ -static noinline char *put_dec(char *buf, u64 num) +static noinline char *put_dec(char *buf, uint64_t num) { while (1) { unsigned rem;

On Wed, Oct 15, 2014 at 04:38:34AM -0600, Simon Glass wrote:
Use the correct type required by do_div().
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

Use inttypes.h and uint64_t to correct the code so that it will not issue warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.
Signed-off-by: Simon Glass sjg@chromium.org ---
include/common.h | 14 +++++++++++++- lib/display_options.c | 14 +++++--------- 2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/common.h b/include/common.h index 02befa6..3ccde60 100644 --- a/include/common.h +++ b/include/common.h @@ -256,7 +256,19 @@ int cpu_init(void); /* */ phys_size_t initdram (int); int display_options (void); -void print_size(unsigned long long, const char *); + +/** + * print_size() - Print a size with a suffic + * + * print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB", + * xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string + * (like "\n") + * + * @size: Size to print + * @suffix String to print after the size + */ +void print_size(uint64_t size, const char *suffix); + int print_buffer(ulong addr, const void *data, uint width, uint count, uint linelen);
diff --git a/lib/display_options.c b/lib/display_options.c index 4c0c886..d5d17b2 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -7,6 +7,7 @@
#include <config.h> #include <common.h> +#include <inttypes.h> #include <version.h> #include <linux/ctype.h> #include <asm/io.h> @@ -21,15 +22,10 @@ int display_options (void) return 0; }
-/* - * print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB", - * xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string - * (like "\n") - */ -void print_size(unsigned long long size, const char *s) +void print_size(uint64_t size, const char *s) { unsigned long m = 0, n; - unsigned long long f; + uint64_t f; static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'}; unsigned long d = 10 * ARRAY_SIZE(names); char c = 0; @@ -43,7 +39,7 @@ void print_size(unsigned long long size, const char *s) }
if (!c) { - printf("%llu Bytes%s", size, s); + printf("%" PRIu64 " Bytes%s", size, s); return; }
@@ -127,7 +123,7 @@ int print_buffer(ulong addr, const void *data, uint width, uint count, else x = lb.uc[i] = *(volatile uint8_t *)data; #ifdef CONFIG_SYS_SUPPORT_64BIT_DATA - printf(" %0*llx", width * 2, x); + printf(" %0*" PRIx64, width * 2, x); #else printf(" %0*x", width * 2, x); #endif

On Wed, Oct 15, 2014 at 04:38:35AM -0600, Simon Glass wrote:
Use inttypes.h and uint64_t to correct the code so that it will not issue warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/x86/lib/relocate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index 526daaf..faca38f 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -16,6 +16,7 @@ */
#include <common.h> +#include <inttypes.h> #include <libfdt.h> #include <malloc.h> #include <asm/u-boot-x86.h> @@ -94,7 +95,7 @@ int do_elf_reloc_fixups(void) *offset_ptr_ram += gd->reloc_off; } else { debug(" %p: rom reloc %x, ram %p, value %x," - " limit %lx\n", re_src, + " limit %" PRIXPTR "\n", re_src, re_src->r_offset, offset_ptr_ram, *offset_ptr_ram, CONFIG_SYS_TEXT_BASE + size);

On Wed, Oct 15, 2014 at 04:38:36AM -0600, Simon Glass wrote:
Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/cmd_scsi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c index b3f7687..cbc107e 100644 --- a/common/cmd_scsi.c +++ b/common/cmd_scsi.c @@ -10,6 +10,7 @@ */ #include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/processor.h> #include <scsi.h> #include <image.h> @@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, blks=0; } debug("scsi_read_ext: startblk " LBAF - ", blccnt %x buffer %lx\n", + ", blccnt %x buffer %" PRIXPTR "\n", start, smallblks, buf_addr); if (scsi_exec(pccb) != true) { scsi_print_error(pccb); @@ -401,7 +402,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, buf_addr+=pccb->datalen; } while(blks!=0); debug("scsi_read_ext: end startblk " LBAF - ", blccnt %x buffer %lx\n", start, smallblks, buf_addr); + ", blccnt %x buffer %" PRIXPTR "\n", start, smallblks, buf_addr); return(blkcnt); }
@@ -445,7 +446,7 @@ static ulong scsi_write(int device, lbaint_t blknr, start += blks; blks = 0; } - debug("%s: startblk " LBAF ", blccnt %x buffer %lx\n", + debug("%s: startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n", __func__, start, smallblks, buf_addr); if (scsi_exec(pccb) != true) { scsi_print_error(pccb); @@ -454,7 +455,7 @@ static ulong scsi_write(int device, lbaint_t blknr, } buf_addr += pccb->datalen; } while (blks != 0); - debug("%s: end startblk " LBAF ", blccnt %x buffer %lx\n", + debug("%s: end startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n", __func__, start, smallblks, buf_addr); return blkcnt; }

On Wed, Oct 15, 2014 at 04:38:37AM -0600, Simon Glass wrote:
Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org:
Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org
common/cmd_scsi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c index b3f7687..cbc107e 100644 --- a/common/cmd_scsi.c +++ b/common/cmd_scsi.c @@ -10,6 +10,7 @@ */ #include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/processor.h> #include <scsi.h> #include <image.h> @@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, blks=0; } debug("scsi_read_ext: startblk " LBAF
", blccnt %x buffer %lx\n",
", blccnt %x buffer %" PRIXPTR "\n", start, smallblks, buf_addr);
The root cause of the problem is to use uintptr_t provided by the compiler.
"unsigned long" can store a pointer whether it is 32bit or 64bit system. (I have never seen LLP64 on Unix-like 64bit system.)

Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/usb_storage.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c index 6ac358d..eb7706c 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -33,6 +33,7 @@
#include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/byteorder.h> #include <asm/processor.h>
@@ -1071,7 +1072,7 @@ unsigned long usb_stor_read(int device, lbaint_t blknr, blks = blkcnt;
debug("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF - " buffer %lx\n", device, start, blks, buf_addr); + " buffer %" PRIxPTR "\n", device, start, blks, buf_addr);
do { /* XXX need some comment here */ @@ -1101,7 +1102,7 @@ retry_it: ss->flags &= ~USB_READY;
debug("usb_read: end startblk " LBAF - ", blccnt %x buffer %lx\n", + ", blccnt %x buffer %" PRIxPTR "\n", start, smallblks, buf_addr);
usb_disable_asynch(0); /* asynch transfer allowed */ @@ -1145,7 +1146,7 @@ unsigned long usb_stor_write(int device, lbaint_t blknr, blks = blkcnt;
debug("\nusb_write: dev %d startblk " LBAF ", blccnt " LBAF - " buffer %lx\n", device, start, blks, buf_addr); + " buffer %" PRIxPTR "\n", device, start, blks, buf_addr);
do { /* If write fails retry for max retry count else @@ -1176,8 +1177,8 @@ retry_it: } while (blks != 0); ss->flags &= ~USB_READY;
- debug("usb_write: end startblk " LBAF ", blccnt %x buffer %lx\n", - start, smallblks, buf_addr); + debug("usb_write: end startblk " LBAF ", blccnt %x buffer %" + PRIxPTR "\n", start, smallblks, buf_addr);
usb_disable_asynch(0); /* asynch transfer allowed */ if (blkcnt >= USB_MAX_XFER_BLK)

On Wed, Oct 15, 2014 at 04:38:38AM -0600, Simon Glass wrote:
Use the inttypes header file to provide this.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

These types are problematic because they are typically declared in a non-standard way in U-Boot. For example, U-Boot uses 'long long' for int64_t even on a 64-bit machine whereas stdint.h uses 'long'. Similarly, U-Boot always uses 'long' for intptr_t whereas stdint.h mostly uses 'int'.
This simple test script runs a few toolchains on a few archs to check for warnings.
Signed-off-by: Simon Glass sjg@chromium.org ---
test/stdint/int-types.c | 13 ++++++++++ test/stdint/test-includes.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh
diff --git a/test/stdint/int-types.c b/test/stdint/int-types.c new file mode 100644 index 0000000..2660084 --- /dev/null +++ b/test/stdint/int-types.c @@ -0,0 +1,13 @@ +#include <common.h> +#include <inttypes.h> + +int test_types(void) +{ + uintptr_t uintptr = 0; + uint64_t uint64 = 0; + u64 u64_val = 0; + + printf("uintptr = %" PRIuPTR "\n", uintptr); + printf("uint64 = %" PRIu64 "\n", uint64); + printf("u64 = %" PRIu64 "\n", u64_val); +} diff --git a/test/stdint/test-includes.sh b/test/stdint/test-includes.sh new file mode 100755 index 0000000..077bdc7 --- /dev/null +++ b/test/stdint/test-includes.sh @@ -0,0 +1,58 @@ +#!/bin/bash + +# Test script to check uintptr_t and 64-bit types for warnings +# +# It builds a few boards with different toolchains. If there are no warnings +# then all is well. +# +# Usage: +# +# Make sure that your toolchains are correct at the bottom of this file +# +# Then: +# ./test/stdint/test-includes.sh + +out=/tmp/test-includes.tmp + +try_test() { + local board=$1 + local arch=$2 + local soc=$3 + local gcc=$4 + local flags="$5" + + echo $@ + if ! which ${gcc} >/dev/null 2>&1; then + echo "Not found: ${gcc}" + return + fi + + rm -rf ${out} + mkdir -p ${out} + touch ${out}/config.h + mkdir -p ${out}/generated + touch ${out}/generated/generic-asm-offsets.h + mkdir -p ${out}/include/asm + ln -s $(pwd)/arch/${arch}/include/asm/arch-${soc} \ + ${out}/include/asm/arch + + cmd="${gcc} -c -D__KERNEL__ ${flags} \ + -fno-builtin -ffreestanding \ + -Iarch/${arch}/include \ + -Iinclude \ + -I${out} -I${out}/include \ + -include configs/${board}.h test/stdint/int-types.c \ + -o /dev/null" + $cmd +} + +# Run a test with and without CONFIG_USE_STDINT +try_both() { + try_test $@ + try_test $@ -DCONFIG_USE_STDINT +} + +# board arch soc path-to-gcc +try_both sandbox sandbox - gcc +try_both coreboot x86 - x86_64-linux-gnu-gcc +try_both seaboard arm tegra20 /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-gcc

On Wed, Oct 15, 2014 at 04:38:39AM -0600, Simon Glass wrote:
These types are problematic because they are typically declared in a non-standard way in U-Boot. For example, U-Boot uses 'long long' for int64_t even on a 64-bit machine whereas stdint.h uses 'long'. Similarly, U-Boot always uses 'long' for intptr_t whereas stdint.h mostly uses 'int'.
This simple test script runs a few toolchains on a few archs to check for warnings.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!

+Jeroen
Hi,
On 15 October 2014 04:38, Simon Glass sjg@chromium.org wrote:
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2): Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8): ext4: Use inttypes for printf() string Use uint64_t for time types Use uint64_t instead of u64 in put_dec() Tidy up data sizes and function comment in display_options x86: Use correct printf() format string for uintptr_t scsi: Use correct printf() format string for uintptr_t usb: Use correct printf() format string for uintptr_t test: Add a simple test to detected warnings with uint64_t, uintptr_t
Are there any comments on this series? I'm keen to clean up the printf() types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
README | 5 + arch/sandbox/include/asm/types.h | 5 + arch/x86/include/asm/types.h | 5 + arch/x86/lib/relocate.c | 3 +- common/cmd_scsi.c | 9 +- common/usb_storage.c | 11 +- config.mk | 5 + fs/ext4/ext4_common.c | 3 +- include/common.h | 19 ++- include/compiler.h | 11 +- include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++ include/linux/types.h | 9 +- include/stdlib.h | 12 ++ lib/display_options.c | 14 +- lib/time.c | 12 +- lib/vsprintf.c | 2 +- test/stdint/int-types.c | 13 ++ test/stdint/test-includes.sh | 58 ++++++++ 18 files changed, 450 insertions(+), 33 deletions(-) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh
-- 2.1.0.rc2.206.gedb03e5
Regards, Simon

Hello Simon,
On 24-10-14 03:03, Simon Glass wrote:
+Jeroen
Hi,
On 15 October 2014 04:38, Simon Glass sjg@chromium.org wrote:
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2): Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8): ext4: Use inttypes for printf() string Use uint64_t for time types Use uint64_t instead of u64 in put_dec() Tidy up data sizes and function comment in display_options x86: Use correct printf() format string for uintptr_t scsi: Use correct printf() format string for uintptr_t usb: Use correct printf() format string for uintptr_t test: Add a simple test to detected warnings with uint64_t, uintptr_t
Are there any comments on this series? I'm keen to clean up the printf() types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
No comments from my side. clang seem to digest this fine.
Regards, Jeroen

Hi Simon, attempt two..
On 24-10-14 03:03, Simon Glass wrote:
+Jeroen
Hi,
On 15 October 2014 04:38, Simon Glass sjg@chromium.org wrote:
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2): Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8): ext4: Use inttypes for printf() string Use uint64_t for time types Use uint64_t instead of u64 in put_dec() Tidy up data sizes and function comment in display_options x86: Use correct printf() format string for uintptr_t scsi: Use correct printf() format string for uintptr_t usb: Use correct printf() format string for uintptr_t test: Add a simple test to detected warnings with uint64_t, uintptr_t
Are there any comments on this series? I'm keen to clean up the printf() types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
No comments from my side. clang seem to digest this fine.
Regards, Jeroen

Hi Jeroen,
On 24 October 2014 11:06, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hi Simon, attempt two..
On 24-10-14 03:03, Simon Glass wrote:
+Jeroen
Hi,
On 15 October 2014 04:38, Simon Glass sjg@chromium.org wrote:
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2): Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8): ext4: Use inttypes for printf() string Use uint64_t for time types Use uint64_t instead of u64 in put_dec() Tidy up data sizes and function comment in display_options x86: Use correct printf() format string for uintptr_t scsi: Use correct printf() format string for uintptr_t usb: Use correct printf() format string for uintptr_t test: Add a simple test to detected warnings with uint64_t, uintptr_t
Are there any comments on this series? I'm keen to clean up the printf() types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
No comments from my side. clang seem to digest this fine.
OK that's good. Thanks for trying it out.
Regards, Simon
participants (5)
-
Jeroen Hofstee
-
Masahiro YAMADA
-
Masahiro Yamada
-
Simon Glass
-
Tom Rini