[M3devel] unsafety in RTAllocator (Malloc/Free)

[Tony Hosking]

This will highly likely break.  Let me take a look and see if there's  
an alternative.

On 3 Feb 2009, at 19:58, Jay wrote:

>
>> What do you need them for? RTAllocator is there so one can allocate
>
> How do I get a typecode in C?
>
> Perhaps the attached is unnecessarily elaborate?
> Or the new/dispose functions should be moved to Modula-3?
> Or eliminated and the small number of callers can say NEW(ARRAY OF  
> CHAR, Uucontext.Size)?
>
>
> - Jay
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Tue, 3 Feb 2009 19:35:38 +1100
>> CC: jkrell at elego.de; m3devel at elegosoft.com
>> Subject: Re: [M3devel] unsafety in RTAllocator (Malloc/Free)
>>
>> On 3 Feb 2009, at 19:07, Jay wrote:
>>
>>>
>>> Sorry, fair enough. I don't think about safety much.
>>>
>>> al
>>> 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.
>>
>> What do you need them for? RTAllocator is there so one can allocate
>> by typecode. I don't see the point of Malloc/Free.
>>
>>> 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?
>>
>> The first is an explicit exception while the latter is implicit.
>>
>>> Why don't Malloc, GetUntracedOpenArray, GetUntracedObj, etc. raise
>>> OutOfMemory directly?
>>
>> Because the exception is implicit. Any procedure can raise a
>> RuntimeError.
>>
>>>
>>>
>>>
>>> - 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).
> <Uucontext.c><Uucontext.h><Uucontext.i3>