[Top][All Lists]

[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++

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]