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
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
