Simon Glover wrote:
> Well, one issue with this patch is that Parrot will now segfault if
> (s>buflen + addlen) < 0. It doesn't seem possible to actually provoke
> this behaviour at the moment, however - string_grow is only called
> from one place in string_replace, and the code in string_repl
On Mon, 15 Apr 2002, Dan Sugalski wrote:
> At 10:26 PM +0200 4/15/02, Peter Gibbs wrote:
> >
> >Note that string_grow still has the problem with not bothering to allocate a
> >new buffer if copysize is zero, e.g. if we are expanding a previously empty
> >buffer.
> >
> >I have submitted a patch f
hat bad. ;)
Thanks,
Mike Lambert
Dan Sugalski wrote:
> Date: Mon, 15 Apr 2002 14:15:04 -0400
> From: Dan Sugalski <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Resync time...
>
> I just checked in some fixes to the GC and memory systems that should
> (theor
Dan Sugalski wrote:
> This feels excessively hackish. It's OK if we were welding in COW to
> an existing code base, but we're not--if we put it in, we put it in
> right.
>
> Right, in this case, is using the COW flag bit in the Buffer
> structure and making the changes to the appropriate string_*
At 11:21 PM +0200 4/15/02, Peter Gibbs wrote:
> > Is this still needed with the update to Parrot_allocate to use
>> buffers? I think I took care of that.
>
>No, Parrot_allocate still sets buflen to the original requested 'size'; not
>the inflated 'req_size' - I'm not sure what you intended.
I i
> Is this still needed with the update to Parrot_allocate to use
> buffers? I think I took care of that.
No, Parrot_allocate still sets buflen to the original requested 'size'; not
the inflated 'req_size' - I'm not sure what you intended.
The behaviour of Parrot_allocate needs to clearly defined
At 11:07 PM +0200 4/15/02, Peter Gibbs wrote:
>Dan Sugalski wrote:
>
>> This has been applied too. There's something bugging me about it--I
>> think there may be issues, and I'd really like it if we made sure we
>> had a bunch of zero-length string tests in the test suite.
>
>The only issue I a
At 4:59 PM -0400 4/15/02, Mike Lambert wrote:
>Looks like this latest broke galatic and momentum boxes on tinderbox.
>Can't assigned to a casted pointer. I think the following patch should
>help.
Applied, thanks.
--
Dan
--
Dan Sugalski wrote:
> This has been applied too. There's something bugging me about it--I
> think there may be issues, and I'd really like it if we made sure we
> had a bunch of zero-length string tests in the test suite.
The only issue I am currently aware of with zero-length strings is the fac
Looks like this latest broke galatic and momentum boxes on tinderbox.
Can't assigned to a casted pointer. I think the following patch should
help.
Mike Lambert
Index: classes/array.pmc
===
RCS file: /cvs/public/parrot/classes/array.
At 10:26 PM +0200 4/15/02, Peter Gibbs wrote:
>
>Note that string_grow still has the problem with not bothering to allocate a
>new buffer if copysize is zero, e.g. if we are expanding a previously empty
>buffer.
>
>I have submitted a patch for this previously, but since string_grow has now
>change
Note that string_grow still has the problem with not bothering to allocate a
new buffer if copysize is zero, e.g. if we are expanding a previously empty
buffer.
I have submitted a patch for this previously, but since string_grow has now
changed, herewith a resynced patch.
--
Peter Gibbs
EmKel Sy
At 3:03 PM -0400 4/15/02, Simon Glover wrote:
> Looks pretty good here. One minor thing I noticed: the change to
> string_grow means that we've got an unused local variable, which
> the patch below gets rid of.
Applied. I'd hope the compilers would optimize that away, but it's
best to not be
Looks pretty good here. One minor thing I noticed: the change to
string_grow means that we've got an unused local variable, which
the patch below gets rid of.
Simon
--- string.c.oldMon Apr 15 14:55:09 2002
+++ string.cMon Apr 15 14:59:56 2002
@@ -72,7 +72,6 @@
*/
STRING *
st
I just checked in some fixes to the GC and memory systems that should
(theoretically) make Parrot a darn sight more stable. Some
particularly stupid things (like we never ran through the Buffer pool
to collect their memory, nor did we mark aggregate's Buffer structs
as live) were fixed, as wer
15 matches
Mail list logo
