Re: Another correction to string patch

[Dan Sugalski]

At 10:32 PM 12/31/2001 +0200, Peter Gibbs wrote:
>- Original Message -
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > Yup. Destroyed strings just get their buffer pointers set to NULL. GC'll
> > collect things up. Also means COW string buffers can share pointers to the
> > same buffer.
> >
>
>Dan/David
>
>With regard to COW strings - would the buffer-related parameters (eg
>bufstart, buflen, bufused) then not be linked to the buffer rather than the
>string? ie should we have two structs (STRING & BUFFER) rather than one
>combined one, with STRING pointing to BUFFER rather than directly to memory?

Nope. COW strings would, when writing, get a new buffer and update the 
values as need be. You just need to make sure that the string functions are 
updating the values in the buffer header and not external code.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Another correction to string patch

[Peter Gibbs]

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> Yup. Destroyed strings just get their buffer pointers set to NULL. GC'll
> collect things up. Also means COW string buffers can share pointers to the
> same buffer.
>

Dan/David

With regard to COW strings - would the buffer-related parameters (eg
bufstart, buflen, bufused) then not be linked to the buffer rather than the
string? ie should we have two structs (STRING & BUFFER) rather than one
combined one, with STRING pointing to BUFFER rather than directly to memory?

Peter Gibbs

Re: Another correction to string patch

[Dan Sugalski]

At 10:15 AM 12/31/2001 -1000, [EMAIL PROTECTED] wrote:
> >You have also forgotten to free the second allocation. I see that you call
>
>My understanding is that string destroy will go away or become a noop with GC
>(Dan is this correct?).  So I intentionally did not mess with it.

Yup. Destroyed strings just get their buffer pointers set to NULL. GC'll 
collect things up. Also means COW string buffers can share pointers to the 
same buffer.

I'll add the patch anyway, though, since we don't have COW strings yet.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Another correction to string patch

[jacobsl001]

>You have also forgotten to free the second allocation. I see that you call

My understanding is that string destroy will go away or become a noop with GC
(Dan is this correct?).  So I intentionally did not mess with it.

David

Another correction to string patch

[Peter Gibbs]

David

You have also forgotten to free the second allocation. I see that you call
free_string(), which is in resources.c, but don't use the matching
new_string_header() function in that file - are these not intended to be a
matched pair for future GC purposes? I am assuming for now that both free()
calls should go in free_string() rather than one in string_destroy() but I
don't know exactly what you and/or Dan intended here.

Peter Gibbs
EmKel Systems


Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.2
diff -c -r1.2 resources.c
*** resources.c 13 Dec 2001 00:51:10 -  1.2
--- resources.c 31 Dec 2001 20:03:28 -
***
*** 27,31 
--- 27,32 
  }

  void free_string(STRING *string) {
+   free(string->bufstart);
free(string);
  }