On Wed, Oct 31, 2012 at 3:43 PM, Eric Wong <normalperson / yhbt.net> wrote:
> "headius (Charles Nutter)" <headius / headius.com> wrote:
>> * For folks doing crypto stuff that want to know exactly how big the
>>   buffer is right away, this provides a way to do so.
>
> I'm not sure exactly what you mean.  Do you mean to avoid leaving
> sensitive data in the heap from realloc()?  Yes it would help, but
> I think this is a poor API for that purpose.

For security, you don't want strings to be growing and copying stuff
around in memory, so being able to allocate a specific size ahead of
time is useful.

> Perhaps special methods like String#secure_cat and String#secure_wipe
> is more obvious for security-concious users.

And if secure_cat didn't use realloc (because it could leave sensitive
data on the heap) you'd *still* have a need to preallocate what you
need. That doesn't solve anyhting.

>> I won't try to argue whether realloc is consistently efficient across
>> platforms or not. It seems like it's not guaranteed to be on any
>> platform.
>
> I absolutely agree this can help performance regardless of platform,
> however...
>
>> It's also such a tiny addition...why not?
>
> I'm not a VM expert, but shouldn't it be possible for the VM to track
> the growth of strings allocated at different call sites and
> automatically optimize preallocations as time goes on?

A sufficiently smart compiler can do anything, of course. However I
know of no VMs that track the eventual size of objects allocated at a
given call site and eagerly allocate that memory, and such an
optimization would be very tricky to do right.

- Charlie