[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] use consistent naming for allocating unsaf
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] use consistent naming for allocating unsafe SRFI-4 accessors |
Date: |
Sun, 26 Feb 2012 20:17:37 +0100 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Feb 21, 2012 at 11:25:30AM +0100, Felix wrote:
> The attached patch changes some internal SRFI-4 accessors to use the
> correct naming scheme ("C_a_u_i_..." for allocating, unsafe inline
> functions). Also, a bug in the length-check for "f64vector-ref" is
> fixed.
I decided to apply this patch since us argueing about deprecation
stuff is pretty much unrelated to the patch, which also contains
an important bugfix.
But I figured that there's some trouble when trying to compile master
using an old Chicken. Older Chickens will rewrite to the old vector-ref
calls, but use the new chicken.h even when building a bootstrap compiler.
This means it will be impossible to upgrade a master install without
jumping through hoops:
libchicken-boot-stage1.a(srfi-4-static.o): In function `f_3059':
srfi-4.c:(.text+0xec6f): undefined reference to `C_a_i_f64vector_ref'
libchicken-boot-stage1.a(srfi-4-static.o): In function `f_3030':
srfi-4.c:(.text+0xf0a6): undefined reference to `C_a_i_f32vector_ref'
libchicken-boot-stage1.a(srfi-4-static.o): In function `f_3001':
srfi-4.c:(.text+0xf4dd): undefined reference to `C_a_i_s32vector_ref'
libchicken-boot-stage1.a(srfi-4-static.o): In function `f_2972':
srfi-4.c:(.text+0xf914): undefined reference to `C_a_i_u32vector_ref'
gmake[2]: *** [chicken-boot-stage1] Error 1
A simple workaround is to invoke make with the C_COMPILER_OPTIONS
and pass "-DC_a_i_f32vector_ref=C_a_u_i_f32vector_ref ...".
However, I was wondering how this will affect the building of development
snapshots. I assume those are built automatically? This process
would break the same way a manual build would break.
A compromise would be to keep around the deprecated macros for a while
until people have updated or a new dev snapshot is available which people
can use for bootstrapping.
I'm not arguing to add __attribute__((deprecated)) right now, I'm just
concerned with a sane upgrade path.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth