[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Re: Patchset related to array functions

From: Daniel Llorens
Subject: [PATCH] Re: Patchset related to array functions
Date: Thu, 14 Jul 2016 17:41:45 +0200

On 14 Jul 2016, at 11:46, Andy Wingo <address@hidden> wrote:

> Thanks for the update.
> On Tue 12 Jul 2016 19:16, Daniel Llorens <address@hidden> 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?

The manual doesn't seem to list which platforms we support, or I can't find it. 
I know that bugs are reported on the list occasionally for Solaris etc. which I 
guess counts as exotic nowadays.

The wiki mentions GNU, GNU/Linux, BSD, MinGW and Cygwin. All those systems have 
C99 compilers. Apparently the list of supported platforms for Emacs (future 
versions at least) is the same, plus a few proprietary Unixes all of which I 
assume have C99 compilers (plus gcc runs in all of them).

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

I think we'd want C89/C90 users to still be able to #include <libguile.h>. 

>  (3) Most importantly, what is the impact on inlining?  See the comment
>      in __scm.h around line 165.

Apparently the standard practice in C99 is to put inline definition in the 
header and extern declaration in the .c, while with ‘Guile inline’ both 
SCM_INLINE and SCM_INLINE_IMPLEMENTATION are in the header. I can try to fix 
Guile to follow the C99 practice and remove most of the #define guards. Would a 
patch doing this be accepted? I'd welcome advice on how to test such a patch. 
E.g. with both -O2 and -O0 or so. I'm mostly a C++ programmer and I don't want 
to mess anything up.

The source has a lot of guarding against the compiler landscape of the 90s that 
might not be necessary today.

> If you want your patch set to depend on C99 that's fine, but you have to
> answer these questions first for the project as a whole and get some
> consensus.

That is a very reasonable viewpoint. Since C99 was just a minor convenience to 
me, I withdraw that particular patch. I have rebased everything to avoid the 
C99 requirement. Revised patchset attached.

Attachment: 0001-Fix-compilation-of-rank-0-typed-array-literals.patch
Description: Binary data

Attachment: 0002-Remove-scm_from_contiguous_array-array-contiguous-fl.patch
Description: Binary data

Attachment: 0003-Avoid-unneeded-internal-use-of-array-handles.patch
Description: Binary data

Attachment: 0004-Reuse-SCM_BYTEVECTOR_TYPED_LENGTH-in-scm_array_get_h.patch
Description: Binary data

Attachment: 0005-Remove-deprecated-array-functions.patch
Description: Binary data

Attachment: 0006-Support-typed-arrays-in-some-sort-functions.patch
Description: Binary data

Attachment: 0007-Do-not-use-array-handles-in-scm_vector.patch
Description: Binary data

Attachment: 0008-Speed-up-for-multi-arg-cases-of-scm_ramap-functions.patch
Description: Binary data

Attachment: 0009-Special-case-for-array-map-with-three-arguments.patch
Description: Binary data

Attachment: 0010-New-functions-array-from-array-from-array-amend.patch
Description: Binary data

Attachment: 0011-New-functions-array-for-each-cell-array-for-each-cel.patch
Description: Binary data

reply via email to

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