I would agree you are correct. If for some reason the encoding was changed, this could cause a problem, and there are probably other areas where this could occur. As they are distinct, they should be treated as such. I am not sure why darbelo changed this. I will check with him before either getting him to change this or fixing it myself.
Cheers, Michael (mikehh) 2009/12/10 Andy Dougherty <[email protected]> > On Thu, 10 Dec 2009, Michael Hind wrote: > > > I don't know if this is relevant but it is defined in pobj.h as: > > Here is the relevant structure (where the first 3 elements are deliberately > the same as in the Buffer structure): > > struct parrot_string_t { > Parrot_UInt flags; > void * _bufstart; > size_t _buflen; > char *strstart; > UINTVAL bufused; > UINTVAL strlen; > UINTVAL hashval; /* cached hash value computation */ > > /* parrot_string_representation_t representation;*/ > const struct _encoding *encoding; > const struct _charset *charset; > }; > > My point is that I don't think it's guaranteed that _bufstart == strstart. > They are equal when the string is initially created, but not guaranteed > to stay that way. For example, in src/string/api.c, in the function > Parrot_str_substr(), there is this excerpt: > > /* do in-place i.e. reuse existing header if one */ > if (replace_dest && d && *d) { > PARROT_ASSERT(src->encoding == Parrot_fixed_8_encoding_ptr); > dest = *d; > > dest->encoding = src->encoding; > dest->charset = src->charset; > > dest->strstart = (char *)src->strstart + true_offset; > dest->bufused = true_length; > > dest->strlen = true_length; > dest->hashval = 0; > } > > where strstart is moved, but bufstart isn't. > > Hence my concern that this patch is wrong in simply replacing strstart by > bufstart. > > -- > Andy Dougherty [email protected] > -- Michael H. Hind Tel: +44 (0) 1224 443 570 Cell: +44 (0) 7877 224 745
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
