Default Integer Pointer Values

[Ty Young]

On 10/3/19 4:51 AM, Maurizio Cimadamore wrote:
>
> On 03/10/2019 05:12, Ty Young wrote:
>> Hi,
>>
>>
>> Recently I've stumbled upon a potential issue in regards to an 
>> allocated integer pointer:
>>
>>
>> Pointer<Integer> valuePointer = <Lib>.scope().allocate(NativeTypes.INT);
>>
>>
>> This basic integer pointer works fine of course. However, for some 
>> reason the pointer has a value already set despite never been given 
>> one. In potential functions that don't have proper return code 
>> values(enums, technically), these values could be potentially seen as 
>> valid values when in reality they are not. In some cases I think 
>> these values can even change from run-to-run, making the issue even 
>> worse.
>>
>>
>> Would the expected behavior here not be to have the wrapped value be 
>> NULL or is there reasons as to why it does this?
>
> Currently, when we allocate memory we do not zero it - which is why 
> you are seeing what you are seeing, I believe.
>
> I agree that we will need to go there - but we're looking at ways to 
> do the zero-init that are more efficient as the current techniques 
> (Unsafe.memorySet) are excessively punitive on large allocations. 
> There was some discussion on this some time ago:
>
> https://mail.openjdk.java.net/pipermail/panama-dev/2019-January/003773.html 
>
>
> I'm trying (among the other things) to pick this up again, and see if 
> some better solution can be achieved here.
>

System memory isn't automatically zeroed at de-allocation? Wouldn't that 
be a potential security risk similar to quick formatting a drive?


Nvidia GPUs don't and you can see frame buffer images from hours ago 
under Linux sometimes which seems kinda dangerous. I always assumed 
system memory was treated better in that regard.


I take it the reason no one does it is because of the general 
performance impact it would have, yes?


Thanks for the answer.


> Maurizio
>