On 12/4/20 4:59 PM, Alexander Richardson wrote:
On Fri, 4 Dec 2020 at 14:51, Hans Petter Selasky <hsela...@freebsd.org> wrote:
Author: hselasky
Date: Fri Dec 4 14:50:55 2020
New Revision: 368329
URL: https://svnweb.freebsd.org/changeset/base/368329
Log:
Fix definition of int64_t and uint64_t when long is 64-bit. This gets the
kernel
shim code in line with the rest of the kernel, sys/x86/include/_types.h.
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
Modified:
head/stand/kshim/bsd_kernel.h
Modified: head/stand/kshim/bsd_kernel.h
==============================================================================
--- head/stand/kshim/bsd_kernel.h Fri Dec 4 14:09:12 2020
(r368328)
+++ head/stand/kshim/bsd_kernel.h Fri Dec 4 14:50:55 2020
(r368329)
@@ -208,9 +208,17 @@ typedef unsigned int uint32_t;
#define _INT32_T_DECLARED
typedef signed int int32_t;
#define _UINT64_T_DECLARED
+#ifndef __LP64__
typedef unsigned long long uint64_t;
+#else
+typedef unsigned long uint64_t;
+#endif
#define _INT16_T_DECLARED
+#ifndef __LP64__
typedef signed long long int64_t;
+#else
+typedef signed long int64_t;
+#endif
typedef uint16_t uid_t;
typedef uint16_t gid_t;
Since we no longer support ancient compilers, could we simplify this
and just use
typedef __UINT64_TYPE__ uint64_t;
typedef __INT64_TYPE__ int64_t;
?
This will work across all architectures and ABIs, and appears to work
starting with GCC 4.5.3 and Clang 3.5:
https://godbolt.org/z/TWavfb
Hi Alexander,
I'm not sure how that definition will work together with existing code,
mixing uint64_t, unsigned long, and unsigned long long. Will this cause
more compiler warnings? This also will affect user-space and ports.
Maybe Konstantin, CC'ed, has some input on this?
--HPS
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
