chicken-hackers
[Top][All Lists]
Advanced

[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



reply via email to

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