c99 support

c99 support

[Andy Wingo]

Hi,

Is there anyone who compiles Guile with a compiler that does not support
C99?  If so, please give platform and compiler.

Thanks,

Andy

Re: c99 support

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Date: Sat, 23 Jun 2018 21:11:29 +0200
> Cc: guile-devel@gnu.org
> 
> Is there anyone who compiles Guile with a compiler that does not support
> C99?  If so, please give platform and compiler.

You mean C99 compiler or C99 C run-time library?  Or both?

MS-Windows (MinGW) doesn't have a C99 compliant C library, although
quite a few of what's needed is present.

Re: c99 support

[Andy Wingo]

On Sat 23 Jun 2018 21:23, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andy Wingo <wingo@pobox.com>
>> Date: Sat, 23 Jun 2018 21:11:29 +0200
>> Cc: guile-devel@gnu.org
>> 
>> Is there anyone who compiles Guile with a compiler that does not support
>> C99?  If so, please give platform and compiler.
>
> You mean C99 compiler or C99 C run-time library?  Or both?
>
> MS-Windows (MinGW) doesn't have a C99 compliant C library, although
> quite a few of what's needed is present.

Hard to say :)  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 want to use C99 inside Guile, and I want to eventually replace
scm_t_uint8 with uint8_t.

I assume MinGW uses GCC.  What version?  I see that the version 6 series
is available on mingw.org.

Andy

Re: c99 support

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: guile-users@gnu.org,  guile-devel@gnu.org
> Date: Sat, 23 Jun 2018 22:07:24 +0200
> 
> > MS-Windows (MinGW) doesn't have a C99 compliant C library, although
> > quite a few of what's needed is present.
> 
> Hard to say :)  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

All of the above is available with reasonably recent versions of MinGW.

> I assume MinGW uses GCC.  What version?  I see that the version 6 series
> is available on mingw.org.

Current versions are 6 and 7, I have 5.3 installed on one of my
machines.  All of them support what you mentioned.

Re: c99 support

[Jan Nieuwenhuizen]

Andy Wingo writes:

> Is there anyone who compiles Guile with a compiler that does not support
> C99?  If so, please give platform and compiler.

As you probably know, I'm currently looking into bootstrapping GuixSD
from source.

I'd like to see Guile become more bootstrappable, i.e., less C code and
perhaps a BOOTSTRAP define to remove all non-essential features and
possibly target bootstrapping it before bootstrapping gcc or even tcc.

I see C99 more as a feature than a problem.  Nyacc supports C99, hardly
any recent software can be built without it.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: c99 support

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]


Andy Wingo <wingo@pobox.com> writes:

> Is there anyone who compiles Guile with a compiler that does not support
> C99?  If so, please give platform and compiler.

Not really the question you asked, and pretty fuzzy, but an anecdote
about a real situation I am aware of:

  In 2015--2016, there was some C code that was supposed to be very
  portable and a notion that using C99 features would not be a problem
  in any environment (as in "In 2015, it's beyond lame not to support
  C99".)  It turned out that it was almost entirely no problem, except
  for one build environment that was using an old compiler, I think from
  MS.  That compiler could handle almost all of C99, except mixed
  declarations and code.

Based on that, I do not expect problems with guile requiring C99,
especially if you refrain from mixed decls/code.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]

Re: c99 support

[Alexander Nasonov]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Greg Troxel wrote:
> 
> Andy Wingo <wingo@pobox.com> writes:
> 
> > Is there anyone who compiles Guile with a compiler that does not support
> > C99?  If so, please give platform and compiler.
> 
> Not really the question you asked, and pretty fuzzy, but an anecdote
> about a real situation I am aware of:
> 
>   In 2015--2016, there was some C code that was supposed to be very
>   portable and a notion that using C99 features would not be a problem
>   in any environment (as in "In 2015, it's beyond lame not to support
>   C99".)  It turned out that it was almost entirely no problem, except
>   for one build environment that was using an old compiler, I think from
>   MS.  That compiler could handle almost all of C99, except mixed
>   declarations and code.

"Granted, however, there is also bad news for C programmers"
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: c99 support

[Andy Wingo]

On Sat 23 Jun 2018 22:12, Andy Wingo <wingo@pobox.com> 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

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 09:39, Andy Wingo <wingo@pobox.com> wrote:
> 
> 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.

You might make a separate C++ header: It turned out too complicated for Bison to maintain the compile as C++ generated C parser.

> 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.

For C++, these are only optional, cf. [1], as they require no padding. So an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving the API unchanged.

1. https://en.cppreference.com/w/cpp/types/integer

Re: c99 support

[Chris Vine]

On Fri, 29 Jun 2018 10:39:33 +0200
Hans Åberg <haberg-1@telia.com> wrote:
> > On 29 Jun 2018, at 09:39, Andy Wingo <wingo@pobox.com> wrote:
> > 
> > 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.
> 
> You might make a separate C++ header: It turned out too complicated for Bison to maintain the compile as C++ generated C parser.
> 
> > 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.
> 
> For C++, these are only optional, cf. [1], as they require no padding. So an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving the API unchanged.
> 
> 1. https://en.cppreference.com/w/cpp/types/integer

The fixed size integer types are optional in C99/11 also, depending on
whether the platform provides a fixed size integer of the type in
question without padding and (for negative integers) a two's complement
representation.  If, say, uint8_t is available in stdint.h for C, it
will be available for C++.  §21.4.1/2 of C++17 makes this even more
explicit: "The [cstdint] header defines all types and macros the
same as the C standard library header <stdint.h>".

I imagine guile will not run on any platform that does not support 8
and 32 bit fixed size integers.

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 12:10, Chris Vine <vine35792468@gmail.com> wrote:
> 
>> For C++, these are only optional, cf. [1], as they require no padding. So an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving the API unchanged.
>> 
>> 1. https://en.cppreference.com/w/cpp/types/integer
> 
> The fixed size integer types are optional in C99/11 also, depending on
> whether the platform provides a fixed size integer of the type in
> question without padding and (for negative integers) a two's complement
> representation.  

Yes, I saw that, too. It is important to ensure two's complement, too, which the other types do not.

> If, say, uint8_t is available in stdint.h for C, it
> will be available for C++.  §21.4.1/2 of C++17 makes this even more
> explicit: "The [cstdint] header defines all types and macros the
> same as the C standard library header <stdint.h>".

Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__.

> I imagine guile will not run on any platform that does not support 8
> and 32 bit fixed size integers.

I would think all CPUs support those types nowadays, so it is rather theoretical.

Re: c99 support

[Chris Vine]

On Fri, 29 Jun 2018 12:34:07 +0200
Hans Åberg <haberg-1@telia.com> wrote:
> > On 29 Jun 2018, at 12:10, Chris Vine <vine35792468@gmail.com> wrote:
> > 
> >> For C++, these are only optional, cf. [1], as they require no padding. So an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving the API unchanged.
> >> 
> >> 1. https://en.cppreference.com/w/cpp/types/integer
> > 
> > The fixed size integer types are optional in C99/11 also, depending on
> > whether the platform provides a fixed size integer of the type in
> > question without padding and (for negative integers) a two's complement
> > representation.  
> 
> Yes, I saw that, too. It is important to ensure two's complement, too, which the other types do not.
> 
> > If, say, uint8_t is available in stdint.h for C, it
> > will be available for C++.  §21.4.1/2 of C++17 makes this even more
> > explicit: "The [cstdint] header defines all types and macros the
> > same as the C standard library header <stdint.h>".
> 
> Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__.

In C++17, references to "C" are to ISO/IEC 9899:2011.  References to the
C standard library are to "the library described in Clause 7 of ISO/IEC
9899:2011".  In C++11 and C++14, the references are to ISO/IEC
9899:1999.  By default (if you don't use the -std=c++xx flag) g++-7
compiles according to C++14.

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 17:35, Chris Vine <vine35792468@gmail.com> wrote:
> 
> On Fri, 29 Jun 2018 12:34:07 +0200
> Hans Åberg <haberg-1@telia.com> wrote:
>>> If, say, uint8_t is available in stdint.h for C, it
>>> will be available for C++.  §21.4.1/2 of C++17 makes this even more
>>> explicit: "The [cstdint] header defines all types and macros the
>>> same as the C standard library header <stdint.h>".
>> 
>> Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__.
> 
> In C++17, references to "C" are to ISO/IEC 9899:2011.  References to the
> C standard library are to "the library described in Clause 7 of ISO/IEC
> 9899:2011".  In C++11 and C++14, the references are to ISO/IEC
> 9899:1999.  

Good.

> By default (if you don't use the -std=c++xx flag) g++-7
> compiles according to C++14.

I am using C++17. And gcc7 defaults to C11, so there is an incompatibility with the default g++ C version it seems.