From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#33848: Store references in SBCL-compiled code are "invisible" Date: Mon, 24 Dec 2018 15:57:50 +0100 Message-ID: <875zvjgefl.fsf@gnu.org> References: <87r2e8jpfx.fsf@gnu.org> <87a7kwjnai.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:49570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbRgE-0003Cc-QT for bug-guix@gnu.org; Mon, 24 Dec 2018 09:58:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gbRgA-0000Pe-NX for bug-guix@gnu.org; Mon, 24 Dec 2018 09:58:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59507) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gbRgA-0000PO-AO for bug-guix@gnu.org; Mon, 24 Dec 2018 09:58:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gbRgA-0003pd-6U for bug-guix@gnu.org; Mon, 24 Dec 2018 09:58:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a7kwjnai.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 23 Dec 2018 16:05:57 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Pierre Neidhardt Cc: 33848@debbugs.gnu.org Hi! Pierre Neidhardt skribis: > Thanks for looking into this, Ludo. > > At first glance, I'd say that this is not a compilation option but the way > strings are encoded by default. It seems that multibyte encoding is used= all > over the place by a few compilers including SBCL (and CCL I think). > > One way I know around this (I'm by no mean a Common Lisp expert) is the > flexi-streams package for re-encoding. OK, we need to investigate. > More generally, shouldn't we make the reference scanner a bit smarter? In > particular, how does it handle non-ASCII references? Maybe it would not = be > unreasonable to handle UTF-8 and UCS-4 for instance? Store file names are always ASCII so problems arise when they are stored as UTF-16 or UTF-32/UCS-4. Ludo=E2=80=99.