Blob.resize() to larger size not working?

This is a bit of a contrived example but I think it demonstrates the issue - does blob.resize() not work when you are trying to make a blob larger? I expect the following code to work but instead the blob shrinks each time through the loop…

`function blobStr(bl, readType = ‘c’){
local str = “”;
bl.seek(0);
while(bl.eos() == null){
str += bl.readn(readType) + ", "
}
return str;
}

//Initialize the blob
testBL <- blob(15);
for(local i=0; i<15; i++) testBL.writen(i, ‘b’);
server.log(blobStr(testBL, ‘b’))

local i=0;
while(i < 16){
i++;
//resize the blob smaller then back to its original size but watch it shrink!
testBL.resize(testBL.len()-1);
testBL.resize(testBL.len()+1); //Doesn’t actually do anything?
testBL.seek(testBL.len()-1);
testBL.writen(i, ‘b’)
server.log(blobStr(testBL, ‘b’))
}`

This logs:
014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 1,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 2,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 3,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 4,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 8, 5,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7, 6,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 6, 7,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 5, 8,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 4, 9,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 3, 10,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 2, 11,
2014-01-01 21:48:58 UTC-5: [Device] 0, 1, 12,
2014-01-01 21:48:58 UTC-5: [Device] 0, 13,
2014-01-01 21:48:58 UTC-5: [Device] 14,
2014-01-01 21:48:58 UTC-5: [Device] 15,
2014-01-01 21:48:58 UTC-5: [Device] 16,

This isn’t a huge deal (although the behavior is a bit unexpected to me) because blob.writen() will grow the blob as necessary - but when wanting to expand the blob by a large amount it seems like there could be a performance hit by allocating memory a byte at a time instead of all at once…

The imp’s implementation of blob.resize() works the same way as the one in upstream Squirrel: which is to say, a bit oddly.

It genuinely does reserve space for the blob to grow, so it can indeed help with performance in just the way you describe. However, blob.len() always returns the used size of the blob, which may be less than the allocated size of the blob. (The allocated size isn’t readable from Squirrel, which is really the source of the oddness.)

So when you use blob.resize() to change the allocated size of the blob to a new value larger than len(), it doesn’t change len() – in C++ terms, it acts like string::reserve(), not string::resize(). But when you use it to decrease the allocated size of the blob to less than len(), then len() of course has to be reduced because the subsequent bytes have been freed.

Peter

Thanks for the clarification Peter. The squirrel documentation leaves all of those details out…