Merge branch 'ebassi/c11-toolchain-req-docs' into 'main'

docs: Update toolchain requirement to C11

See merge request GNOME/glib!4082
This commit is contained in:
Philip Withnall 2024-06-14 12:35:06 +00:00
commit 5fdd6507b4
3 changed files with 15 additions and 8 deletions

View File

@ -1,14 +1,15 @@
Toolchain/Compiler requirements Toolchain/Compiler requirements
=== ===
GLib requires a toolchain that supports C99. GLib strongly recommends a toolchain that supports C11, and requires a toolchain
that supports C99.
GLib contains some fall back code that allows supporting toolchains that are not GLib contains some fall back code that allows supporting toolchains that are not
fully C99-compatible. fully C11-compatible.
GLib makes some assumptions about features of the C library and C preprocessor, GLib makes some assumptions about features of the C library and C preprocessor,
compiler and linker that may go beyond what C99 mandates. We will use features compiler and linker that may go beyond what C11 mandates. We will use features
beyond C99 if they are substantially useful and if they are supported in a wide beyond C11 if they are substantially useful and if they are supported in a wide
range of compilers. range of compilers.
In general, we are primarily interested in supporting these four compilers: In general, we are primarily interested in supporting these four compilers:
@ -116,11 +117,10 @@ _Hard requirement._
Your compiler must support `alloca()`, defined in `<alloca.h>` (or `<malloc.h>` Your compiler must support `alloca()`, defined in `<alloca.h>` (or `<malloc.h>`
on Windows) and it must accept a non-constant argument. on Windows) and it must accept a non-constant argument.
(C11) support for type redefinition C11 support for type redefinition
--- ---
**This requirement has been temporarily suspended (on account of OpenBSD _Hard requirement._
carrying an old version of gcc) but it will probably return in the future.**
Your compiler must allow “a typedef name [to] be redefined to denote the same Your compiler must allow “a typedef name [to] be redefined to denote the same
type as it currently does”, as per C11 §6.7, item 3. type as it currently does”, as per C11 §6.7, item 3.
@ -193,4 +193,3 @@ GLib [requires a C99 `stdint.h`](https://gitlab.gnome.org/GNOME/glib/-/merge_req
with all the usual sized integer types (`int8_t`, `uint64_t` and so on), with all the usual sized integer types (`int8_t`, `uint64_t` and so on),
believed to be supported by all relevant Unix platforms/compilers, as well as believed to be supported by all relevant Unix platforms/compilers, as well as
Microsoft compilers since MSVC 2013. Microsoft compilers since MSVC 2013.

View File

@ -215,6 +215,10 @@ G_STATIC_ASSERT (G_SIGNEDNESS_OF (guint64) == 0);
G_STATIC_ASSERT (G_SIGNEDNESS_OF (int64_t) == 1); G_STATIC_ASSERT (G_SIGNEDNESS_OF (int64_t) == 1);
G_STATIC_ASSERT (G_SIGNEDNESS_OF (uint64_t) == 0); G_STATIC_ASSERT (G_SIGNEDNESS_OF (uint64_t) == 0);
/* C11 §6.7, item 3 allows us to rely on this being allowed */
typedef struct Foo Foo;
typedef struct Foo Foo;
/** /**
* g_mem_gc_friendly: * g_mem_gc_friendly:
* *

View File

@ -585,6 +585,10 @@ if cc.get_id() == 'gcc' or cc.get_id() == 'clang'
'-Werror=missing-prototypes', '-Werror=missing-prototypes',
'-Werror=pointer-sign', '-Werror=pointer-sign',
'-Wno-string-plus-int', '-Wno-string-plus-int',
# We require a compiler that supports C11 even though it's not yet a
# strict requirement, so allow typedef redefinition not to break clang and
# older gcc versions.
'-Wno-typedef-redefinition',
] ]
warning_cxx_args = warning_common_args warning_cxx_args = warning_common_args
warning_objc_args = warning_c_args warning_objc_args = warning_c_args