Re: c99 support
> On 29 Jun 2018, at 17:35, Chris Vine wrote: > > On Fri, 29 Jun 2018 12:34:07 +0200 > Hans Åberg 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 ". >> >> 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.
Re: c99 support
On Fri, 29 Jun 2018 12:34:07 +0200 Hans Åberg wrote: > > On 29 Jun 2018, at 12:10, Chris Vine 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 ". > > 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
> On 29 Jun 2018, at 12:10, Chris Vine 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 ". 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
On Fri, 29 Jun 2018 10:39:33 +0200 Hans Åberg wrote: > > On 29 Jun 2018, at 09:39, Andy Wingo 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 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 ". I imagine guile will not run on any platform that does not support 8 and 32 bit fixed size integers.
Re: c99 support
> On 29 Jun 2018, at 09:39, Andy Wingo 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 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
On Sat 23 Jun 2018 22:12, Andy Wingo 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 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
Greg Troxel wrote: > > Andy Wingo 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 signature.asc Description: PGP signature
Re: c99 support
Andy Wingo 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. signature.asc Description: PGP signature
Re: c99 support
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 | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: c99 support
On Sat 23 Jun 2018 21:23, Eli Zaretskii writes:
>> From: Andy Wingo
>> 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
> From: Andy Wingo > 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.
c99 support
Hi, Is there anyone who compiles Guile with a compiler that does not support C99? If so, please give platform and compiler. Thanks, Andy
