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
We seem to have broken the Tru64 (Ermine) and the Mac OS X 10.1 (glastig)
tinderboxen with yesterday's patchfest. Ermine is failing on the
super-huge string test for some reason. Did we have a regression in this
area somewhere? The redhat box I just added (see below) seems to
demonstrate the probl
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
14 matches
Mail list logo
