Anton Shepelev
anton****@gmail*****
Sat Mar 3 04:54:27 JST 2018
ForkKeith Marshall:
> We need to keep malloc.h, for Microsoft compati-
> bility, but I wonder if it may be worthwhile to
> introduce an extra layer of indirection, via a new
> alloca.h header, to extend compatibility towards
> GNU paradigms? It wouldn't be difficult to imple-
> ment, but a counter argument may be that use of
> alloca() is discouraged, (by Michael Kerrisk's
> Linux manpage).
>From what I have read and understood:
1. alloca() is practically identical with the
neoclassical feature of C, variable-length ar-
rays.
2. alloca() is no more dangerous than recursion
or large local arrays.
3. considering the low-level spirit of C,
alloca() should seem a natural generalisation
of control over stack memory.
I therefore disagree with the criticism in the man
page. On the other hand, alloca() is not inter-
changeable with malloc() even for local use because
the result of the former shall never be passed to
free().
>From my point of view, it is better to support
alloca() the GNU way, as it will help me compile
more *nix programs with less problems. But I under-
stand that it may not be the goal of MinGW.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]