Is replacing alloca(3) where possible a good thing to do?

[twilight]

Hello,

I again,
in cddl/* alloca(3) is used very intensively for creating dynamic arrays.
But, well, it's kinda obsolete and sometimes not safe and portable.
Is replacing alloca(3) with dynamic arrays a good thing? Or should
everything be left as it is?

Thanks in advance.

[Ed Schouten]

Hi,

Post by twilight
I again,
in cddl/* alloca(3) is used very intensively for creating dynamic arrays.
But, well, it's kinda obsolete and sometimes not safe and portable.
Is replacing alloca(3) with dynamic arrays a good thing? Or should
everything be left as it is?

With dynamic arrays you are referring to C99's Variable-Length Arrays
(VLAs), right?

The advantage of C99 VLAs is that they are standardised, unlike
alloca(), which is good. What I also like about them compared to
alloca() is that they are easier to implement from a compiler's point
of view, as they are bound to a block scope and not to a function.
alloca() can be called in a loop, for example, which is quite nasty.

Still, C99 VLAs and alloca() both share the problem that as there is
no upper bound on the allocated space, you may easily run into stack
overflows. Especially for externally-facing APIs, you may have
absolutely no idea whether it's safe to allocate a buffer having a
size provided by the caller. This is one of the reasons why C11 made
them optional again.

So the best solution is to replace any use of alloca() with
malloc()/free(). That said, as you were interested in making such
changes in cddl/*, I guess you'll also have to go through the process
of sending those patches to Illumos.

[Joerg Sonnenberger]

Post by Ed Schouten
So the best solution is to replace any use of alloca() with
malloc()/free(). That said, as you were interested in making such
changes in cddl/*, I guess you'll also have to go through the process
of sending those patches to Illumos.

Blindly replacing them makes little sense. alloca provides zero-cost
freeing and is also much cheaper than malloc. It should be limited to
reasonable sizes though, where reasonable is typically < 1MB per
thread.

Joerg

[Jan Bramkamp]

Post by twilight
Hello,
I again,
in cddl/* alloca(3) is used very intensively for creating dynamic arrays.
But, well, it's kinda obsolete and sometimes not safe and portable.
Is replacing alloca(3) with dynamic arrays a good thing? Or should
everything be left as it is?
Thanks in advance.

alloca() and VLAs aren't completely interchangeable e.g. alloca() should
return pointers with the same alignment as malloc while a VLA is just
correctly aligned for its member type. Some types can't be stored in
VLAs without casting e.g. if you want to store an incomplete type like a
struct ending with a zero sized array you can't put such a struct in a
union with a char array to allocate space for the array elements. In
such cases alloca() is easier to read and more portable. You won't
notice the unaligned accesses on a x86 CPU but they would trap on a
SPARC or ARM (<= ARMv5). Other CPUs silently round down your unaligned
pointer to the next natural aligned address.

[Pedro Giffuni]

FWIW,

After some discussion with one of the principal Illumos developers it is
clear that they won't accept replacing alloca(3) for the sake of
"portability". You also can't always replace alloca(3) with VLAs anyways.

Pedro.

[Allan Jude]

Post by Pedro Giffuni
FWIW,
After some discussion with one of the principal Illumos developers it is
clear that they won't accept replacing alloca(3) for the sake of
"portability". You also can't always replace alloca(3) with VLAs anyways.
Pedro.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

The one time I tried to use it, it went very badly, as it returns a
pointer, but the actual amount of memory was less than I had requested,
and so it smashed everything.

[twilight]

Post by Allan Jude
The one time I tried to use it, it went very badly, as it returns a
pointer, but the actual amount of memory was less than I had requested,
and so it smashed everything.

That is a known issue with alloca, so it shouldn't be used with big
amounts of memory (it creates objects on stack, so stack overflow can be
reached easily).

But, well, creating a really big array would do the same. Also, deep
recursion will also smash the stack.

So we don't have a deal like "remove alloca and your stack will be
safe". But still, it's obsolete and compiler dependent. I'd better not
stick to it.

[Cedric Blancher]

Who was the "principal Illumos developer"? I remember some heated
discussions, mostly rooted in 'we stick with ANSI C' and because the
CTF/dwarf tools in Illumos were unable to handle VLA and no one was
interested in fixing the BUGS in their toolchain, so the cheapest
solution was done: VLA was declared persona non grata. Saves company
money.

Typical Sun policy which was one of the reasons which sealed the
downfall of Sun Microsystems.

But this is NO ARGUMENT for FreeBSD...

Ced

Post by Pedro Giffuni
FWIW,
After some discussion with one of the principal Illumos developers it is
clear that they won't accept replacing alloca(3) for the sake of
"portability". You also can't always replace alloca(3) with VLAs anyways.
Pedro.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Pedro Giffuni]

Post by Cedric Blancher
Who was the "principal Illumos developer"? I remember some heated
discussions, mostly rooted in 'we stick with ANSI C' and because the
CTF/dwarf tools in Illumos were unable to handle VLA and no one was
interested in fixing the BUGS in their toolchain, so the cheapest
solution was done: VLA was declared persona non grata. Saves company
money.

Yes, the non-accessibility of VLAs for Dtrace was the main argument.
This was a private conversation with Garrett D'Amore who did some nice
enhancements to our printf(1).

Post by Cedric Blancher
Typical Sun policy which was one of the reasons which sealed the
downfall of Sun Microsystems.
But this is NO ARGUMENT for FreeBSD...

Our printf(1) implementation has all their enhancements but uses a VLA
instead of alloca.

This said, whatever illumos wants to keep in their code is relevant as
we want to make it easy to merge ZFS and Dtrace changes back and forth.

Pedro.

[Cedric Blancher]

dtrace can do VLA

Are there other arguments?

Ced

Post by Cedric Blancher
Who was the "principal Illumos developer"? I remember some heated
discussions, mostly rooted in 'we stick with ANSI C' and because the
CTF/dwarf tools in Illumos were unable to handle VLA and no one was
interested in fixing the BUGS in their toolchain, so the cheapest
solution was done: VLA was declared persona non grata. Saves company
money.

Yes, the non-accessibility of VLAs for Dtrace was the main argument. This
was a private conversation with Garrett D'Amore who did some nice
enhancements to our printf(1).

Post by Cedric Blancher
Typical Sun policy which was one of the reasons which sealed the
downfall of Sun Microsystems.
But this is NO ARGUMENT for FreeBSD...

Our printf(1) implementation has all their enhancements but uses a VLA
instead of alloca.
This said, whatever illumos wants to keep in their code is relevant as we
want to make it easy to merge ZFS and Dtrace changes back and forth.
Pedro.

[Pedro Giffuni]

Hello;

Post by Cedric Blancher
dtrace can do VLA
Are there other arguments?

It was a while ago and I don't remember other than the fact that
alloca() exists on all platforms and just works fine so why bother.

This was only a discussion in the context of printf(1) and as I wrote we
parted different ways there. If there are other notable cases then
please upstream those changes first.

Pedro.

Post by Cedric Blancher
Ced

Post by Cedric Blancher
Who was the "principal Illumos developer"? I remember some heated
discussions, mostly rooted in 'we stick with ANSI C' and because the
CTF/dwarf tools in Illumos were unable to handle VLA and no one was
interested in fixing the BUGS in their toolchain, so the cheapest
solution was done: VLA was declared persona non grata. Saves company
money.

Yes, the non-accessibility of VLAs for Dtrace was the main argument. This
was a private conversation with Garrett D'Amore who did some nice
enhancements to our printf(1).

Post by Cedric Blancher
Typical Sun policy which was one of the reasons which sealed the
downfall of Sun Microsystems.
But this is NO ARGUMENT for FreeBSD...

Our printf(1) implementation has all their enhancements but uses a VLA
instead of alloca.
This said, whatever illumos wants to keep in their code is relevant as we
want to make it easy to merge ZFS and Dtrace changes back and forth.
Pedro.

[K. Macy]

Post by Pedro Giffuni
Hello;

Post by Cedric Blancher
dtrace can do VLA
Are there other arguments?

It was a while ago and I don't remember other than the fact that alloca()
exists on all platforms and just works fine so why bother.

What problem are we trying to solve? Is there any indication in
practice of stack overruns or are we talking about fixing something
that isn't broken?

-M

Post by Pedro Giffuni
This was only a discussion in the context of printf(1) and as I wrote we
parted different ways there. If there are other notable cases then please
upstream those changes first.
Pedro.

Post by Cedric Blancher
Ced

Post by Cedric Blancher
Who was the "principal Illumos developer"? I remember some heated
discussions, mostly rooted in 'we stick with ANSI C' and because the
CTF/dwarf tools in Illumos were unable to handle VLA and no one was
interested in fixing the BUGS in their toolchain, so the cheapest
solution was done: VLA was declared persona non grata. Saves company
money.

Yes, the non-accessibility of VLAs for Dtrace was the main argument. This
was a private conversation with Garrett D'Amore who did some nice
enhancements to our printf(1).

Post by Cedric Blancher
Typical Sun policy which was one of the reasons which sealed the
downfall of Sun Microsystems.
But this is NO ARGUMENT for FreeBSD...

Our printf(1) implementation has all their enhancements but uses a VLA
instead of alloca.
This said, whatever illumos wants to keep in their code is relevant as we
want to make it easy to merge ZFS and Dtrace changes back and forth.
Pedro.

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers