size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
on any ports Xen might gain. In particular I hope new ports can rely on
__SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is just to start with some hopefully uncontroversial low hanging fruit.

--- a/xen/arch/arm/include/asm/types.h
+++ b/xen/arch/arm/include/asm/types.h
@@ -54,19 +54,6 @@ typedef u64 register_t;
 #define PRIregister "016lx"
 #endif
 
-#if defined(__SIZE_TYPE__)
-typedef __SIZE_TYPE__ size_t;
-#else
-typedef unsigned long size_t;
-#endif
-typedef signed long ssize_t;
-
-#if defined(__PTRDIFF_TYPE__)
-typedef __PTRDIFF_TYPE__ ptrdiff_t;
-#else
-typedef signed long ptrdiff_t;
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_TYPES_H__ */
--- a/xen/arch/x86/include/asm/types.h
+++ b/xen/arch/x86/include/asm/types.h
@@ -32,19 +32,6 @@ typedef unsigned long paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
 
-#if defined(__SIZE_TYPE__)
-typedef __SIZE_TYPE__ size_t;
-#else
-typedef unsigned long size_t;
-#endif
-typedef signed long ssize_t;
-
-#if defined(__PTRDIFF_TYPE__)
-typedef __PTRDIFF_TYPE__ ptrdiff_t;
-#else
-typedef signed long ptrdiff_t;
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __X86_TYPES_H__ */
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -5,6 +5,19 @@
 
 #include <asm/types.h>
 
+#if defined(__SIZE_TYPE__)
+typedef __SIZE_TYPE__ size_t;
+#else
+typedef unsigned long size_t;
+#endif
+typedef signed long ssize_t;
+
+#if defined(__PTRDIFF_TYPE__)
+typedef __PTRDIFF_TYPE__ ptrdiff_t;
+#else
+typedef signed long ptrdiff_t;
+#endif
+
 #define BITS_TO_LONGS(bits) \
     (((bits)+BITS_PER_LONG-1)/BITS_PER_LONG)
 #define DECLARE_BITMAP(name,bits) \

Hi Jan,

On 12/01/2023 14:01, Jan Beulich wrote:
> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
> on any ports Xen might gain. In particular I hope new ports can rely on
> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Julien Grall <jgrall@amazon.com>

I also don't have any strong opinion either way about continuing to use 
types.h or introduce stddef.h.

Cheers,

-- 
Julien Grall

On 12/01/2023 2:01 pm, Jan Beulich wrote:
> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
> on any ports Xen might gain. In particular I hope new ports can rely on
> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thankyou for starting this.

> ---
> This is just to start with some hopefully uncontroversial low hanging fruit.

However, I'd advocate going one step further and making real a
xen/stddef.h header to match our existing stdboot and stdarg, now that
we have fully divorced ourselves from the compiler-provided freestanding
headers.

This way, the type are declared in the usual place in a C environment.

I was then also going to use this approach to start breaking up
xen/lib.h which is a dumping ground of far too much stuff.  In
particular, when we have a stddef.h, I think it is entirely reasonable
to move things like ARRAY_SIZE/count_args()/etc into it, because they
are entirely standard in the Xen codebase.

~Andrew

On 12.01.2023 15:22, Andrew Cooper wrote:
> On 12/01/2023 2:01 pm, Jan Beulich wrote:
>> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
>> on any ports Xen might gain. In particular I hope new ports can rely on
>> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

>> ---
>> This is just to start with some hopefully uncontroversial low hanging fruit.
> 
> However, I'd advocate going one step further and making real a
> xen/stddef.h header to match our existing stdboot and stdarg, now that
> we have fully divorced ourselves from the compiler-provided freestanding
> headers.

Hmm, to be honest I'm not convinced. It'll be interesting to see what
other maintainers think about such further moving away from Linux'es
basic model.

> This way, the type are declared in the usual place in a C environment.
> 
> I was then also going to use this approach to start breaking up
> xen/lib.h which is a dumping ground of far too much stuff.  In
> particular, when we have a stddef.h, I think it is entirely reasonable
> to move things like ARRAY_SIZE/count_args()/etc into it, because they
> are entirely standard in the Xen codebase.

Yet these aren't what people would expect to live there. If we
introduce further std*.h, then I think these would better strictly
conform to what the C standard expects to be put there.

Jan