guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile: What's wrong with this?


From: Bruce Korb
Subject: Re: Guile: What's wrong with this?
Date: Wed, 04 Jan 2012 11:29:51 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

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 #<catch-closure 8b75a0> ...]
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



reply via email to

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