|
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>. Dunno. > (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.
0001-Fix-compilation-of-rank-0-typed-array-literals.patch
Description: Binary data
0002-Remove-scm_from_contiguous_array-array-contiguous-fl.patch
Description: Binary data
0003-Avoid-unneeded-internal-use-of-array-handles.patch
Description: Binary data
0004-Reuse-SCM_BYTEVECTOR_TYPED_LENGTH-in-scm_array_get_h.patch
Description: Binary data
0005-Remove-deprecated-array-functions.patch
Description: Binary data
0006-Support-typed-arrays-in-some-sort-functions.patch
Description: Binary data
0007-Do-not-use-array-handles-in-scm_vector.patch
Description: Binary data
0008-Speed-up-for-multi-arg-cases-of-scm_ramap-functions.patch
Description: Binary data
0009-Special-case-for-array-map-with-three-arguments.patch
Description: Binary data
0010-New-functions-array-from-array-from-array-amend.patch
Description: Binary data
0011-New-functions-array-for-each-cell-array-for-each-cel.patch
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |