On 03 April 2002 05:09 Bryan C. Warnock wrote: > We should probably have Parrot_allocate (and realloc) actually pass back > how much it *really* allocated, as opposed to having to guess and/or > reimplement the rounding algorithm everywhere. > > Either > > buflen = Parrot_allocate(interpreter, requested_size, &bufstart); > > or > > bufstart = Parrot_allocate(interpreter, requested_size, &buflen); > > or something else similar.
My first thoughts on this are that we should go the whole way, and have Parrot_allocate take a Buffer* and a requested size, and let it fill in the bufstart and buflen parameters (as in the not-yet-implemented Parrot_reallocate patch). This would cause problems for anybody trying to use Parrot_allocate to create temporary storage; however, that is a highly dangerous thing to do anyway without taking the possible impact of GC into consideration. The only place I can find a call to Parrot_allocate that does not place the resulting pointer into a buffer is in the code for 'open' in io.ops. This code is interesting anyway, because it will fail if the second allocate attempt triggers a collection; since this is only for a mode string, the chances are very small, but not zero. Why are we passing a C-style string around inside parrot anyway? -- Peter Gibbs EmKel Systems