From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Program received signal SIGSEGV, Segmentation fault. Date: Fri, 16 Nov 2012 21:19:16 -0500 Message-ID: References: <50A67F45.3030504@gmail.com> <87haops6cj.fsf@tines.lan> <50A698F3.2090009@gnu.org> <50A6A01E.8060909@gnu.org> <87a9uhs0mb.fsf@tines.lan> <50A6CD05.3010706@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5540cd6d35edf04cea78215 X-Trace: ger.gmane.org 1353118767 17740 80.91.229.3 (17 Nov 2012 02:19:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Nov 2012 02:19:27 +0000 (UTC) Cc: Mark H Weaver , guile-devel Development To: Bruce Korb Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 17 03:19:38 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TZY0O-0004yN-9u for guile-devel@m.gmane.org; Sat, 17 Nov 2012 03:19:36 +0100 Original-Received: from localhost ([::1]:54161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZY0E-00022x-4W for guile-devel@m.gmane.org; Fri, 16 Nov 2012 21:19:26 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZY08-00022l-T0 for guile-devel@gnu.org; Fri, 16 Nov 2012 21:19:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZY05-0003oG-Qa for guile-devel@gnu.org; Fri, 16 Nov 2012 21:19:20 -0500 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:48563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZY05-0003oC-J6; Fri, 16 Nov 2012 21:19:17 -0500 Original-Received: by mail-ob0-f169.google.com with SMTP id lz20so3843706obb.0 for ; Fri, 16 Nov 2012 18:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=J9++B2UGo4/7QGh2a0CSmNlwWspxKJA18PwjTwd8mUY=; b=mhZuhABzGMA/d8wOsg5k3IFJo3ndbklBC0Ji+Du9pVHMRZSxCBkfVFRZVFNSdL/aV7 MCApsTym19d4ebEXP2myZRukLnBA8BkVxEG3y6zadFpBrOoNShEHIeR69tge8bNzskT3 KBNs6yDfW/RuHHbNYfQu7JL3vlFvoF9LO/wVsT/9tXpEin6IOw9A0NEDmBvGvNPgVsXj wnp/FEKvwf0Vq9Lq5k2Bmvcx5KVHKq3/3QTXkYa4ln20+CLruEDFwsRYrmUjmYi7OzRo USEJwbNjD2/yzlUKQhdrBuWo7S1SU1WyeIcbsi7hVRK2XqKscQKQucA/QpM7l/Hdzwuh Y1oA== Original-Received: by 10.60.171.164 with SMTP id av4mr5476791oec.59.1353118756593; Fri, 16 Nov 2012 18:19:16 -0800 (PST) Original-Received: by 10.76.120.236 with HTTP; Fri, 16 Nov 2012 18:19:16 -0800 (PST) In-Reply-To: <50A6CD05.3010706@gnu.org> X-Google-Sender-Auth: trRIkcj4nCb8cj5R6xARHgJ9EjM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.214.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15192 Archived-At: --bcaec5540cd6d35edf04cea78215 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Fri, Nov 16, 2012 at 6:32 PM, Bruce Korb wrote: > On 11/16/12 13:23, Mark H Weaver wrote: > >> Actually, it was scm_from_utf8_string, since GUILE_VERSION was 200005 > > > > Okay, that's the problem. You told Guile that the C string was encoded > > in UTF-8, but actually it was encoded in Latin-1: > > OK, so I tried latin1, too. (replacing scm_from_utf3_string with > scm_from_latin1_string). That also does not work. It replaced the > 0xA9 character with '?'. I am no expert on character encodings, but we've seen errors like this before where it turned out that Guile was attempting to display the character on a terminal which didn't support it, and then the terminal converted it into '?'. Could there have been some change in how Guile displays strings that caused this error? Did it used to show a \-escape sequence? > What it all boils down to is that > I am looking for string handling functions that will handle the > NUL terminated list of bytes and keep its nose out of the contents > of the string. Period. Full stop. > Could you explain what you're trying to do a little more? If you're calling a function that looks at characters on a string object that doesn't contain valid characters, then it will fail. If you have a NUL-terminated list of bytes that contains only characters valid in some encoding, then the scm_from_*_string functions are supposed to wrap it. So do you intend to make a string object and then never look inside? Or are you going to roll your own string-handling starting from byte sequences? The rest of your email suggests not. Thanks, Noah --bcaec5540cd6d35edf04cea78215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Fri, Nov= 16, 2012 at 6:32 PM, Bruce Korb <bkorb@gnu.org> wrote:
On 11/16/12 13:23, Mark H Weaver wrote:
>> Actually, it was scm_from_utf8_string, since GUILE_VERSION was 200= 005
>
> Okay, that's the problem. =A0You told Guile that the C string was = encoded
> in UTF-8, but actually it was encoded in Latin-1:

OK, so I tried latin1, too. =A0(replacing scm_from_utf3_string with scm_from_latin1_string). =A0That also does not work. =A0It replaced the
0xA9 character with '?'.

I am no ex= pert on character encodings, but we've seen errors like this before whe= re it turned out that Guile was attempting to display the character on a te= rminal which didn't support it, and then the terminal converted it into= '?'. Could there have been some change in how Guile displays strin= gs that caused this error? Did it used to show a \-escape sequence?
=A0
What it all boils down to is t= hat
I am looking for string handling functions that will handle the
NUL terminated list of bytes and keep its nose out of the contents
of the string. =A0Period. =A0Full stop.

Could you explain what you're trying to do a little more? If you'r= e calling a function that looks at characters on a string object that doesn= 't contain valid characters, then it will fail. If you have a NUL-termi= nated list of bytes that contains only characters valid in some encoding, t= hen the scm_from_*_string functions are supposed to wrap it. So do you inte= nd to make a string object and then never look inside? Or are you going to = roll your own string-handling starting from byte sequences? The rest of you= r email suggests not.
=A0
Thanks,
Noah

--bcaec5540cd6d35edf04cea78215--