[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: c99 support
From: |
Andy Wingo |
Subject: |
Re: c99 support |
Date: |
Fri, 29 Jun 2018 09:39:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
On Sat 23 Jun 2018 22:12, Andy Wingo <address@hidden> writes:
> Is there anyone who compiles Guile with a compiler that does not support
> C99? If so, please give platform and compiler.
>
> I think my questions are limited to, in decreasing order of importance:
>
> * Is there any system that we target that doesn't have C99 stdint.h
> and stddef.h ?
>
> * Is there any system that we target that doesn't support C99 inline
> functions?
>
> * C99 mixed decls and statements?
>
> * C99 one-line comments (// foo) ?
>
> * C99 compound literals? ((struct x) { 1, 2 }) ?
>
> * stdbool.h
>
> I would like to use C99 inside Guile, and I want to eventually replace
> scm_t_uint8 with uint8_t.
Thanks all for the responses. It would seem that the first four
features of C99 are OK for all platforms that we target, with the
following caveats:
* We should avoid using C++ keywords (e.g. throw) in Guile API files.
* We might want to avoid mixed decls and statements in inline functions
in Guile API files.
We should probably avoid stdbool.h and compound literals, for C++
reasons.
In Guile 3.0 (master branch), the types "scm_t_uint8" and so on are now
deprecated. My recommendation is that all users switch to use
e.g. "uint8_t", "ptrdiff_t", etc from <stdint.h> instead of the
scm_t_uint8, etc definitions that they are now using. The definitions
are compatible on all systems, AFAIU, and on GNU, scm_t_uint8 has long
been a simple typedef for uint8_t.
If you make the change while targetting current Guile (2.2), then you'll
won't have deprecation warnings when 3.0 comes out.
Cheers,
Andy