16:55 <Perelandric> Just curious, do `Pointer._alloc/_realloc` zero memory? I assume so, but wanted to be certain.

17:06 <jemc> Perelandric: I don't think it does, but not sure

17:07 <jemc> it uses `pony_alloc` internally, and I don't think `pony_alloc` zeroes memory, but again, not sure

17:12 <jemc> Perelandric: yes, I ran a quick test of an infinite loop allocating a ten-byte buffer with `pony_alloc` and printing the bytes - eventually I start seeing some non-zero ones

17:13 <jemc> so, bytes are not zeroed for you - you have to expect undefined contents of memory when you allocate

17:18 <Perelandric> jemc: Thanks for checking. What got me thinking about it was the update to Array.append...

17:18 <Perelandric> I noticed that the `_size` is alway set after the loop instead of inside it, and it made me wonder...

17:19 <Perelandric> if there could be any crafty way of forcing an error during that loop, if it could expose arbitrary memory.

17:22 <Perelandric> Makes sense that `_size` should always end up at the expected value though.

17:49 <jemc> Perelandric: that's why the `_size` is set outside the `try` block

17:50 <jemc> and it's not set to the expected len, but to the actual number of iterations of the loop, which should match the actual number of bytes

17:50 <jemc> of course, if you can find an edge case I didn't notice, we should repair it

17:56 <Perelandric> jemc: Ugh, of course, sorry about that. I was thinking of the `copy_len` instead of `n`.

17:56 <Perelandric> In that case, the `n` could be elimiated altogether. I think that's what threw me off at first.

17:57 <Perelandric> Unless there's another reason `_size = _size + 1` shouldn't be in the loop.

17:58 <Perelandric> Oh, it would still be needed for `seq(offset + n)`

17:59 <Perelandric> I'll shut up now... ;)