> From: Andy Wingo
> Date: Wed, 31 Aug 2016 11:46:19 +0200
> Cc: guile-devel
>
> Hah! Turns out we have been compiling in GCC's default mode the whole
> time, which is gnu11.
The default is version-dependent. Only GCC 5.x switched to gnu11,
previous versions used gnu90, AFAIK.
On 31 Aug 2016, at 11:46, Andy Wingo wrote:
> On Wed 31 Aug 2016 11:28, Andy Wingo writes:
>
>> On Thu 14 Jul 2016 20:20, Andy Wingo writes:
>>
>>> I think the concerns are:
>>>
>>> (1) Do inlined definitions get inlined?
>>> (2) Are external definitions reified as well?
>>> (3) Do we avoid
On Wed 31 Aug 2016 11:28, Andy Wingo writes:
> On Thu 14 Jul 2016 20:20, Andy Wingo writes:
>
>> I think the concerns are:
>>
>> (1) Do inlined definitions get inlined?
>> (2) Are external definitions reified as well?
>> (3) Do we avoid reifying definitions in each compilation unit?
>> (4) C
Hi :)
Hope you had a good holiday.
On Thu 14 Jul 2016 20:20, Andy Wingo writes:
> I think the concerns are:
>
> (1) Do inlined definitions get inlined?
> (2) Are external definitions reified as well?
> (3) Do we avoid reifying definitions in each compilation unit?
> (4) Can you dlsym() an i
On Sat, 16 Jul 2016 11:07:40 +0200
Andy Wingo wrote:
[snip]
> I would like stdint.h though :)
I agree. stdint.h is required by C++11, Appendix D5, to be available
in C++11 and later, with the same meaning as in C99, but in practice it
was available before then. It is provided by gcc-4.4 with th
On Fri 15 Jul 2016 12:52, Chris Vine writes:
> On Thu, 14 Jul 2016 17:41:45 +0200
> Daniel Llorens wrote:
> [snip]
>> I think we'd want C89/C90 users to still be able to #include
>> . Dunno.
>
> libguile.h can also at present be included in C++89/03/11/14 code by
> design - all the necessary "ex
On Fri 15 Jul 2016 19:41, Mark H Weaver writes:
> Andy Wingo writes:
>
>> (2) Can we use C99 in our public interface, or just internally? If we
>> use it publically, what should we change? No more scm_t_uint8 I
>> hope, besides for back-compat? This patch set does not have to
>>
Andy Wingo writes:
> (2) Can we use C99 in our public interface, or just internally? If we
> use it publically, what should we change? No more scm_t_uint8 I
> hope, besides for back-compat? This patch set does not have to
> include these changes, but we should have a plan.
On 14 Jul 2016, at 20:20, Andy Wingo wrote:
> I think the concerns are:
>
> (1) Do inlined definitions get inlined?
> (2) Are external definitions reified as well?
> (3) Do we avoid reifying definitions in each compilation unit?
> (4) Can you dlsym() an inline function?
>
> All these answers s
On Thu, 14 Jul 2016 17:41:45 +0200
Daniel Llorens wrote:
[snip]
> I think we'd want C89/C90 users to still be able to #include
> . Dunno.
libguile.h can also at present be included in C++89/03/11/14 code by
design - all the necessary "extern C" stuff is there. I would hope
that would continue, b
On Thu 14 Jul 2016 17:41, Daniel Llorens writes:
> On 14 Jul 2016, at 11:46, Andy Wingo wrote:
>
>> (1) Can we support C99 on all targets we care about?
>
> Emacs
http://git.savannah.gnu.org/cgit/emacs.git/tree/configure.ac#n764
"Emacs needs C99". Sweet! We check this point off.
>> (2) Ca
Thanks for the update.
On Tue 12 Jul 2016 19:16, Daniel Llorens writes:
> Subject: [PATCH 01/12] Compile in C99 mode
This could be a good change but it is not the fastest path to patch
review :) There are three considerations here:
(1) Can we support C99 on all targets we care about?
(2)
On Tue 12 Jul 2016 09:48, Daniel Llorens writes:
> @@ -175,19 +175,19 @@ dnl investigation of problems with "64" system and
> library calls on
> dnl Darwin (MacOS X). The libguile code (_scm.h) assumes that if a
> dnl system has stat64, it will have all the other 64 APIs too; but on
> dnl
13 matches
Mail list logo
