[PATCH] Fix compilation with iso C standard

[PATCH] Fix compilation with iso C standard

[Simon Zeni]

The whole repo can now be built with iso C standard (c89, c99 and c11)

Signed-off-by: Simon Zeni <simon@bl4ckb0ne.ca>
---

References to the compiler extension `typeof` have been changed to
`__typeof__` for portability. See [GCC's documentation][1] about
`typeof`.

I've added the definition `_POSIX_C_SOURCE` in the source files that are
using functions not defined in by the POSIX standard, fixing a few
occurences of `sigset_t` not being defined.

I've also added the definition `_BSD_SOURCE` in `setup.c` and
`syscall.c` for respectively the `madvise` function (I know that
`posix_madvise` exists, but there is not equivalent for
`MADV_DONTFORK`), and `syscall`.

Cheers,

Simon

[1]: https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

 src/include/liburing/barrier.h | 8 ++++----
 src/queue.c                    | 2 ++
 src/register.c                 | 2 ++
 src/setup.c                    | 3 +++
 src/syscall.c                  | 2 ++
 5 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/include/liburing/barrier.h b/src/include/liburing/barrier.h
index a4a59fb..89ac682 100644
--- a/src/include/liburing/barrier.h
+++ b/src/include/liburing/barrier.h
@@ -56,17 +56,17 @@ static inline T io_uring_smp_load_acquire(const T *p)
 #include <stdatomic.h>

 #define IO_URING_WRITE_ONCE(var, val)				\
-	atomic_store_explicit((_Atomic typeof(var) *)&(var),	\
+	atomic_store_explicit((_Atomic __typeof__(var) *)&(var),	\
 			      (val), memory_order_relaxed)
 #define IO_URING_READ_ONCE(var)					\
-	atomic_load_explicit((_Atomic typeof(var) *)&(var),	\
+	atomic_load_explicit((_Atomic __typeof__(var) *)&(var),	\
 			     memory_order_relaxed)

 #define io_uring_smp_store_release(p, v)			\
-	atomic_store_explicit((_Atomic typeof(*(p)) *)(p), (v), \
+	atomic_store_explicit((_Atomic __typeof__(*(p)) *)(p), (v), \
 			      memory_order_release)
 #define io_uring_smp_load_acquire(p)				\
-	atomic_load_explicit((_Atomic typeof(*(p)) *)(p),	\
+	atomic_load_explicit((_Atomic __typeof__(*(p)) *)(p),	\
 			     memory_order_acquire)
 #endif

diff --git a/src/queue.c b/src/queue.c
index 24fde2d..053d430 100644
--- a/src/queue.c
+++ b/src/queue.c
@@ -1,4 +1,6 @@
 /* SPDX-License-Identifier: MIT */
+#define _POSIX_C_SOURCE 200112L
+
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/mman.h>
diff --git a/src/register.c b/src/register.c
index f3787c0..994aaff 100644
--- a/src/register.c
+++ b/src/register.c
@@ -1,4 +1,6 @@
 /* SPDX-License-Identifier: MIT */
+#define _POSIX_C_SOURCE 200112L
+
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/mman.h>
diff --git a/src/setup.c b/src/setup.c
index 8e14085..ce2ff4f 100644
--- a/src/setup.c
+++ b/src/setup.c
@@ -1,4 +1,6 @@
 /* SPDX-License-Identifier: MIT */
+#define _BSD_SOURCE
+
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/mman.h>
@@ -6,6 +8,7 @@
 #include <errno.h>
 #include <string.h>
 #include <stdlib.h>
+#include <signal.h>

 #include "liburing/compat.h"
 #include "liburing/io_uring.h"
diff --git a/src/syscall.c b/src/syscall.c
index 598b531..3f9aa9f 100644
--- a/src/syscall.c
+++ b/src/syscall.c
@@ -1,4 +1,6 @@
 /* SPDX-License-Identifier: MIT */
+#define _BSD_SOURCE
+
 /*
  * Will go away once libc support is there
  */
--
2.29.1

Re: [PATCH] Fix compilation with iso C standard

[Jens Axboe]

On 10/27/20 9:18 PM, Simon Zeni wrote:
> The whole repo can now be built with iso C standard (c89, c99 and c11)
> 
> Signed-off-by: Simon Zeni <simon@bl4ckb0ne.ca>
> ---
> 
> References to the compiler extension `typeof` have been changed to
> `__typeof__` for portability. See [GCC's documentation][1] about
> `typeof`.
> 
> I've added the definition `_POSIX_C_SOURCE` in the source files that are
> using functions not defined in by the POSIX standard, fixing a few
> occurences of `sigset_t` not being defined.
> 
> I've also added the definition `_BSD_SOURCE` in `setup.c` and
> `syscall.c` for respectively the `madvise` function (I know that
> `posix_madvise` exists, but there is not equivalent for
> `MADV_DONTFORK`), and `syscall`.

All of this good stuff should be in the commit message before
the '---' or it won't make it into the git log. Which would be a
shame!

I get a bunch of these with this applied:

In file included from /usr/include/x86_64-linux-gnu/sys/types.h:25,
                 from setup.c:4:
/usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
      |   ^~~~~~~


-- 
Jens Axboe

Re: [PATCH] Fix compilation with iso C standard

[Simon Zeni]

On Wed Oct 28, 2020 at 12:31 PM EDT, Jens Axboe wrote:
> All of this good stuff should be in the commit message before
> the '---' or it won't make it into the git log. Which would be a
> shame!
>
> I get a bunch of these with this applied:
>
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:25,
> from setup.c:4:
> /usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and
> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
> 187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
> _DEFAULT_SOURCE"
> | ^~~~~~~

I didn't want to fill the commit message with my patch explanation but I
can make a v2 to fix that definition warning and add the text into the
commit if you want.

Simon

Re: [PATCH] Fix compilation with iso C standard

[Jens Axboe]

On 10/28/20 7:00 PM, Simon Zeni wrote:
> On Wed Oct 28, 2020 at 12:31 PM EDT, Jens Axboe wrote:
>> All of this good stuff should be in the commit message before
>> the '---' or it won't make it into the git log. Which would be a
>> shame!
>>
>> I get a bunch of these with this applied:
>>
>> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:25,
>> from setup.c:4:
>> /usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and
>> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
>> 187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
>> _DEFAULT_SOURCE"
>> | ^~~~~~~
> 
> I didn't want to fill the commit message with my patch explanation but I
> can make a v2 to fix that definition warning and add the text into the
> commit if you want.

That's what it's there for! The commit message is basically useless
without that added, the only bit you left is a throw-away.

-- 
Jens Axboe