[Vm-dev] Building OSVM in Windows 11 and Cygwin64 ...

Jakob Reschke jakres+squeak at gmail.com
Fri Dec 30 23:58:39 UTC 2022


Probably to avoid stack overflows, _malloca allocates from the heap rather
than from the stack if the size exceeds a threshold. That's why you have to
call _freea. I assume that _freea inspects the address or some internals
about the allocated memory and then either does nothing for stack memory or
does something like free() for heap memory...

It might be justified to let the compiler always insert _freea
automatically (it would have to make sure not to mix implementations
though), but this is C and C programmers love to do everything by
themselves, don't they? ;-) It would mean a special case for the
compiler, but on the other hand if _alloca and _malloca are usually
built-ins, they are already special cases. Still there might be some
portability concerns if the C standard (which does not even include
alloca...) does not require that a C compiler insert _freea automatically.

During this Internet research I have also seen a mention that alloca() is
in some environments replaced with a fallback library implementation that
uses heap memory. And that you have to call alloca(0) every now and then to
release the memory. So much for portability.



Am Sa., 31. Dez. 2022 um 00:41 Uhr schrieb Eliot Miranda <
eliot.miranda at gmail.com>:

>
>
>
> On Fri, Dec 30, 2022 at 2:51 PM Jakob Reschke <jakres+squeak at gmail.com>
> wrote:
>
>>
>> That's why (quoted from the doc page):
>>
>> Unlike _alloca, which doesn't require or permit a call to free to free
>> the memory so allocated, _malloca requires the use of _freea
>> <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/freea?view=msvc-170> to
>> free memory.
>>
>
> Still not a good enough justification, IMO.  They could modify the
> compiler to plant a call to _freea on return.  I'm also curious to see if
> _freea actually does anything.  The whole point of alloca is that
> deallocation is automatic on return because the memory is stack allocated.
>
> Am Fr., 30. Dez. 2022 um 23:07 Uhr schrieb Eliot Miranda <
>> eliot.miranda at gmail.com>:
>>
>>>
>>>
>>>
>>> On Mon, Dec 19, 2022 at 9:29 AM Ron Teitelbaum <ron at usmedrec.com> wrote:
>>>
>>>>
>>>> Just saw this:
>>>>
>>>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca?view=msvc-170
>>>>
>>>> _alloca
>>>>
>>>> Article
>>>> 10/26/2022
>>>>
>>>> Allocates memory on the stack. This function is *deprecated* because a
>>>> more secure version is available; see:
>>>>
>>>>  _malloca
>>>> <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=msvc-170>
>>>> .
>>>>
>>>
>>> Mucroshaft are such irritating *FUCKS*.  It has exactly the same
>>> signature as alloca.  Why didn't they just upgrade the implementation
>>> instead of forcing everyone to rewrite their code??
>>>
>>>>
>>>>
>>>>
>>>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=msvc-170
>>>>
>>>> Requirements
>>>>
>>>> RoutineRequired header
>>>> _malloca<malloc.h>
>>>>
>>>> All the best,
>>>>
>>>> Ron Teitelbaum
>>>>
>>>>
>>>> On Mon, Dec 19, 2022 at 12:00 PM Marcel Taeumel <marcel.taeumel at hpi.de>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi all!
>>>>>
>>>>> Has anybody tried to build OSVM in Windows 11 via Cygwin64?
>>>>>
>>>>> clang-8 does not work because "_alloca" cannot be found ... hmm...
>>>>>
>>>>>
>>>>> So, who implements _alloca? It's not msvcrt.dll ... how to find that
>>>>> out?
>>>>>
>>>>> Best,
>>>>> Marcel
>>>>>
>>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20221231/2e7174f2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31608 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20221231/2e7174f2/attachment-0001.png>


More information about the Vm-dev mailing list