[M3devel] unsafety in RTAllocator (Malloc/Free)

[Jay]

Sorry, fair enough. I don't think about safety much.
 
 
Can I put these in a new unsafe RTAllocateUnsafe.i3 or RTUnsafeAllocator.i3?
  And then the function names I had come up with MallocUninitialized, MallocZeroed.
 
 
Using array of char seems non-ideal to me somehow.
It seems like a "workaround".
It doesn't seem really any safer than not having a type at all.
I understand, the array, the type, does imply a size, and so I would get some bounds checking against it, except I never access these things anyway, I just pass them on to unsafe C code.
 
 
Related but tangential question, something I also didn't pay close enough attention to:
What is the deal with OutOfMemory vs. RuntimeError.T.OutOfMemory?
 
 
Why don't Malloc, GetUntracedOpenArray, GetUntracedObj, etc. raise OutOfMemory directly?
 
 
 - Jay


----------------------------------------
> To: jkrell at elego.de
> Date: Mon, 2 Feb 2009 22:21:53 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Jay Krell writes:
>>CVSROOT: /usr/cvs
>>Changes by: jkrell at birch. 09/02/03 06:17:25
>>
>>Modified files:
>> cm3/m3-libs/m3core/src/runtime/common/: RTAllocator.i3
>> RTAllocator.m3
>>
>>Log message:
>> expose RTAllocator.MallocZeroed (calloc), and RTAllocator.Free
>
> RTAllocator isn't UNSAFE is it (it isn't in my installation)? Surely
> you can't have Free in a non-UNSAFE interface...
>
> Mika
>
>> introduce internal RTAlloc.MallocUninitialized
>>
>> These include Disable/EnableSwitching, and
>> raising exceptions upon failure.
>> (Disable/Enable only do something for user threads).