From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruce Korb Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile: What's wrong with this? Date: Wed, 04 Jan 2012 11:29:51 -0800 Message-ID: <4F04A8AF.9020205@gmail.com> References: <4F027F35.5020001@gmail.com> <1325603029.22166.YahooMailNeo@web37906.mail.mud.yahoo.com> <4F032C41.3070300@gmail.com> <877h17hjj2.fsf@netris.org> <1325687351.71432.YahooMailNeo@web37906.mail.mud.yahoo.com> <874nwbs9c4.fsf@pobox.com> <4F048CBB.9020903@gmail.com> <87k457z5mv.fsf@Kagami.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325705403 3265 80.91.229.12 (4 Jan 2012 19:30:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 19:30:03 +0000 (UTC) Cc: "guile-devel@gnu.org" To: Ian Price Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 04 20:29:59 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RiWX9-0001NN-DT for guile-devel@m.gmane.org; Wed, 04 Jan 2012 20:29:59 +0100 Original-Received: from localhost ([::1]:48439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWX8-0006FM-RN for guile-devel@m.gmane.org; Wed, 04 Jan 2012 14:29:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWX5-0006FH-Sm for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiWX4-0003Op-Km for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:55 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:61013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWX4-0003Ok-EG for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:54 -0500 Original-Received: by iacb35 with SMTP id b35so36440848iac.0 for ; Wed, 04 Jan 2012 11:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kHoVDeDivnTkOH0jATzSc3C9V2zLIkshn6OWzzPccXE=; b=WOvIVAB3RjYjbK+WBuDtbM0dIUV1sY6dVvTGdPqZWMF9RjtVq9vI0nrsR4jdeNTXWs wPxGR/pFPX0hDZFn0n0jyP9ygk5ZWddHhKBuKrk4Fw+nKVIjYIFPD2cZG8HLyk8KuQ8k IejvtIyu7MIQjhh0E/4jaDfpkfdta/ijiYCrY= Original-Received: by 10.42.180.9 with SMTP id bs9mr58572076icb.0.1325705393610; Wed, 04 Jan 2012 11:29:53 -0800 (PST) Original-Received: from [10.0.0.2] (adsl-75-0-186-252.dsl.pltn13.sbcglobal.net. [75.0.186.252]) by mx.google.com with ESMTPS id cv10sm113986120igc.0.2012.01.04.11.29.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 11:29:53 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 In-Reply-To: <87k457z5mv.fsf@Kagami.home> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.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:13289 Archived-At: On 01/04/12 10:26, Ian Price wrote: >> Just because an obscure-to-those-not-living-and-breathing-Scheme-daily >> document said it was okay doesn't make it okay to those whacked by it. > There's an old saying, "Ignorance of the law is no excuse". If I wrote C > code that doesn't conform to the C standard I did. The standard changed. My code broke. The fix for read-only string literals was obvious and straight forward. The fix for pointer aliasing is virtually impossible, except to -fno-strict-aliasing for GCC. Yes, new code, fine, but the millions of lines of old code I deal with? No way. I think I've seen a reasonable way to go forward: an option to always copy newly defined strings. I am also a little curious: since this fault occurred on a string brought in via my C function named ag_scm_get() and it created the value with a call to scm_str02scm, shouldn't that function have created a mutable string copy? > Now, if you want to argue your position, it'd be better to argue that > guile goes beyond r[56]rs in making these promises with regards to strings. My number 1 argument may not be the strongest argument. My number 1 argument is that Guile, being an extension language, needs to be as forgiving and easy to use as it can possibly be because its client programmers (programmers using it) want to know as absolutely little as possible about it. No, I do *not* want to read, understand and remember 50 pages of stuff so that I can use Guile as an extension language. The memory barrier is much, *MUCH* lower for other scripting languages. > For instance, substring-fill! as found at > https://www.gnu.org/software/guile/manual/html_node/String-Modification.html > implies that string literals are mutable > > — Scheme Procedure: substring-fill! str start end fill > — C Function: scm_substring_fill_x (str, start, end, fill) > > Change every character in str between start and end to fill. > > (define y "abcdefg") > (substring-fill! y 1 3 #\r) > y > ⇒ "arrdefg" Who knows where I learned the idiom. I learned the minimal amount of Guile needed for my purposes a dozen years ago. My actual problem stems from this: > Backtrace: > In ice-9/boot-9.scm: > 170: 3 [catch #t # ...] > In unknown file: > ?: 2 [catch-closure] > In ice-9/eval.scm: > 420: 1 [eval # ()] > In unknown file: > ?: 0 [string-upcase ""] > > ERROR: In procedure string-upcase: > ERROR: string is read-only: "" > Scheme evaluation error. AutoGen ABEND-ing in template > confmacs.tlib on line 209 > Failing Guile command: = = = = = > > (set! tmp-text (get "act-text")) > (set! TMP-text (string-upcase tmp-text)) What in heck is string-upcase doing trying to write to its input string? Why was the string returned by ag_scm_get() (the function bound to "get") an immutable string anyway? > SCM > ag_scm_get(SCM agName, SCM altVal) > { > tDefEntry* pE; > ag_bool x; > > pE = (! AG_SCM_STRING_P(agName)) ? NULL : > findDefEntry(ag_scm2zchars(agName, "ag value"), &x); > > if ((pE == NULL) || (pE->valType != VALTYP_TEXT)) { > if (AG_SCM_STRING_P(altVal)) > return altVal; > return AG_SCM_STR02SCM(zNil); > } > > return AG_SCM_STR02SCM(pE->val.pzText); > } "AG_SCM_STR02SCM" is either scm_makfrom0str or scm_from_locale_string, depending on the age of the Guile library. "zNil" is a pointer to a NUL byte that is, indeed, in read only memory, but surely scm_from_locale_string would not have been written in a way to detect that and add that attribute because of doing a memory probe. Further, it cannot be implemented in a way that does not copy it because I will most certainly call scm_from_locale_string using a pointer to memory that is immediately deallocated. It *MUST* copy the string. So what is this really about anyway? > I think it would be fair to say that someone could surmise that literal > strings are meant to be mutable from these examples, and, if we do go > down the immutable string literal route these examples would need to be > addressed. :) I think so. Meanwhile, I think the solution to be allowing Guile clients to say, with some initialization code of some sort, "copy my input strings" so the immutability flag is not set. (I do think it correct to not scribble on shared strings....) Thank you for your help! Regards, Bruce