From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: The =?utf-8?b?4oCcYmluYXJ5LWZyaWVuZGx54oCd?= Latin-1 Date: Tue, 25 Jan 2011 14:21:50 +0100 Message-ID: <87hbcxunip.fsf@gnu.org> References: <55051.1700.qm@web37908.mail.mud.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1295961783 26340 80.91.229.12 (25 Jan 2011 13:23:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Jan 2011 13:23:03 +0000 (UTC) Cc: "guile-devel@gnu.org" To: Mike Gran Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 25 14:22:59 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PhirH-0007or-3X for guile-devel@m.gmane.org; Tue, 25 Jan 2011 14:22:55 +0100 Original-Received: from localhost ([127.0.0.1]:35161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhirF-0007AW-Jl for guile-devel@m.gmane.org; Tue, 25 Jan 2011 08:22:53 -0500 Original-Received: from [140.186.70.92] (port=51196 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhiqN-0006Qh-Bk for guile-devel@gnu.org; Tue, 25 Jan 2011 08:22:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhiqJ-0007PV-0g for guile-devel@gnu.org; Tue, 25 Jan 2011 08:21:56 -0500 Original-Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:22296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhiqI-0007Oz-R6 for guile-devel@gnu.org; Tue, 25 Jan 2011 08:21:54 -0500 X-IronPort-AV: E=Sophos;i="4.60,374,1291590000"; d="scan'208";a="73889601" Original-Received: from unknown (HELO nixey) ([193.50.110.208]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Jan 2011 14:21:53 +0100 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 6 =?iso-8859-1?Q?Pluvi=F4se?= an 219 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <55051.1700.qm@web37908.mail.mud.yahoo.com> (Mike Gran's message of "Mon, 24 Jan 2011 15:21:53 -0800 (PST)") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11336 Archived-At: Hello! >> =C2=A0 1. The notion of a =E2=80=9Cbinary-friendly=E2=80=9D ISO-8859-1 e= ncoding?=C2=A0 It=E2=80=99s >> =C2=A0 =C2=A0 actually mostly gone with the iconv change, since every te= xtual >> =C2=A0 =C2=A0 access goes through iconv.=C2=A0 For binary accesses, the = right API is >> =C2=A0 =C2=A0 (rnrs io ports) or similar. > > An equivalent question is if you care about backward compatibility of > legacy ports.=C2=A0 Legacy ports returned strings and were once the only = option. You mean if there=E2=80=99s legacy code using a port of unspecified encodin= g to read binary data, right? The iconv change doesn=E2=80=99t break it on GNU/Linux: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> (define p (open-bytevector-input-port #vu8(0 1 2 3 255= 128))) scheme@(guile-user)> (set-port-encoding! p "ISO-8859-1") scheme@(guile-user)> (read-char p) $14 =3D #\nul scheme@(guile-user)> (read-char p) $15 =3D #\soh scheme@(guile-user)> (read-char p) $16 =3D #\stx scheme@(guile-user)> (read-char p) $17 =3D #\etx scheme@(guile-user)> (read-char p) $18 =3D #\=C3=BF scheme@(guile-user)> (read-char p) $19 =3D #\200 scheme@(guile-user)> (read-char p) $20 =3D # --8<---------------cut here---------------end--------------->8--- However, an iconv implementation may be free to choke on anything that=E2= =80=99s not strictly Latin-1 per , e.g., everything but =E2=80=9C=C3=BF=E2=80=9D in the example above, but tha= t seems highly unlikely. Anyway, as soon as you use a non-Latin-1 locale, ports get opened under that locale=E2=80=99s encoding, which practically makes it impossible to do binary I/O on the ports. >> =C2=A0 2. The #f <=3D> "ISO-8859-1" equivalence for =E2=80=98port-encodi= ng=E2=80=99 and >> =C2=A0 =C2=A0 =E2=80=98set-port-encoding!=E2=80=99.=C2=A0 Likewise, comm= it >> =C2=A0 =C2=A0 d9544bf012b6e343c80b76bd5761b1583cc106a3 makes =E2=80=98po= rt-encoding=E2=80=99 >> =C2=A0 =C2=A0 always return a string and pt->encoding always be non-NULL. > > Is the cost of doing the various=C2=A0string comparisons=C2=A0of port-enc= oding > strings negligible?=C2=A0 It was put in as a (premature) optimization. The new code keeps open iconv conversion descriptors for each port and re-uses them; the only use of pt->encoding is when opening those CDs. Thanks, Ludo=E2=80=99.