On Tuesday 02 April 2002 04:36, Peter Gibbs wrote: > Currently, calling string_make(interp, NULL,0,NULL,0,NULL), as is done by, > for example "new P0, PerlString", calls Parrot_allocate with a required > allocation of zero, which gets converted to 16; a 16-byte buffer is hence > allocated, and its address placed in bufstart. However, buflen will still be > zero, therefore the block will be discarded as soon as any actual content is > assigned to the string.
buflen should be 16, not 0. bufused should be 0. > > Parrot_go_collect uses a slightly different rounding rule, and will allocate > zero bytes to a zero-length buffer; the current allocation address will be > placed in bufstart, but the same address will be used for the next buffer > collected. They should probably round the same. > > Would it be sensible to define 'buflen=0, bufused=0, bufstart=NULL' as a > valid null string? This would impact on any code that assumes bufstart to be > valid. If not, are there any other suggestions for ways to avoid this > proliferation of useless blocks, or should we just let them be created and > discarded? Since nothing should be doing validation of the buffer based on bufstart, but only through bufstart via buflen, it shouldn't matter what bufstart's value is - NULL, or a dummy pointer to itself, for instance, if buflen is 0. The question is what should Parrot do when asked to allocate 0 bytes. Since allocating 0 bytes is rather useless, I agree with the rounding up to 16. -- Bryan C. Warnock [EMAIL PROTECTED]
