Mike Lambert wrote: > Undoing the patch in resources.c seems to fix the problem. > > Changing: > ((Buffer *)buffer)->buflen = req_size; > to: > ((Buffer *)buffer)->buflen = size; > makes it work again.
Just for interest, the problem here is that the rounding is always up to the next multiple of 16. So, for example, a zero-length string would have buflen set to 16 (actually it is set back to zero in string_make, but that just slows the process down slightly); string_copy would ask for a buffer of 16 and get back a buffer of 32, etc, so every time a string is copied, it grows by 16 bytes. This effect is exacerbated by the fact that "set S1, S2" does a string_copy - I am still not sure what is supposed to happen here; I believe that the pure set opcode should just be doing a register copy?? There is a clone opcode which also does a string_copy, which seems reasonable. The only advantage of having buflen always be the actual allocated length would be to remove the rounding logic in go_collect; note that go_collect rounds up only if the length is not already a multiple of 16; this difference in algorithm was where the whole discussion started in the first place. I suggested an increased buflen value specifically for strings, to allow mutable string operations to use the space which has already been allocated anyway. For example, the recently-added 'string_to_cstring' function will always reallocate a buffer the first time it is called for any given string, even though the physical allocation would have been sufficient. -- Peter Gibbs EmKel Systems