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 fact that mem_allocate will allocate 16 bytes during creation, but go_collect will allocate zero space, and hence we end up with multiple buffer headers pointing to the same physical memory address (see previous thread "Definition of a null string?" http://www.mail-archive.com/perl6-internals@perl.org/msg09000.html) This does not seem to cause any problems, since buflen is zero, so the buffer will never be accessed; however it looks very strange when debugging the GC. Attached is a part of my COW patch, which relies on the 'round up to next multiple of 16' behaviour of Parrot_allocate, and makes the additional allocated space available for subsequent use for string expansion. -- Peter Gibbs EmKel Systems Index: string.c =================================================================== RCS file: /home/perlcvs/parrot/string.c,v retrieving revision 1.73 diff -u -r1.73 string.c --- string.c 15 Apr 2002 20:34:28 -0000 1.73 +++ string.c 15 Apr 2002 21:02:38 -0000 @@ -47,13 +47,12 @@ } s = new_string_header(interpreter); - Parrot_allocate(interpreter, s, buflen); + Parrot_allocate(interpreter, s, buflen | 15); s->encoding = encoding; /* Make sure we maintain the flags we might already have on the * string header we just fetched */ s->flags |= flags; s->type = type; - s->buflen = buflen; if (buffer) { mem_sys_memcopy(s->bufstart, buffer, buflen); @@ -73,7 +72,7 @@ STRING * string_grow(struct Parrot_Interp * interpreter, STRING * s, INTVAL addlen) { /* Don't check buflen, if we are here, we already checked. */ - Parrot_reallocate(interpreter, s, s->buflen + addlen); + Parrot_reallocate(interpreter, s, (s->buflen + addlen) | 15); return s; }
