On Mon, Aug 29, 2011 at 1:35 PM, Wolfgang Denk wd@denx.de wrote:
Dear Anton Staaf,
In message CAF6FioWhhqbVQWWPrusb69S2mpfBtoiazxc8x56bkogJmzXZ3g@mail.gmail.com you wrote:
I would like to know, mainly for my education, why you do not want alloca, but are OK with dynamic array sizing (as in the first solution above). My understanding is that they pretty much equate to the same thing. What is it about alloca that is objectionable?
First, I've got bitten by alloca() before, when GCC misbehaved. Admitted, that was in some _very_ old version, but such experience sticks.
Very fair, I have programming constructs I avoid for the same reason. *cough* exceptions *cough*
Second, the behaviour of alloca() depends on a number of non-obvious settings and compiler flags, and results are not always obvious. rom the man page:
Notes on the GNU Version Normally, gcc(1) translates calls to alloca() with inlined code. This is not done when either the -ansi, -std=c89, -std=c99, or the -fno-builtin option is given (and the header <alloca.h> is not included). But beware! By default the glibc version of <stdlib.h> includes <alloca.h> and that contains the line:
#define alloca(size) __builtin_alloca (size)
with messy consequences if one has a private version of this function.
This is nothing I want to have in any production software. OK, you may argument that U-Boot has a strictly controlled environment, but anyway.
Yes, I don't expect that we will allow a custom implementation of alloca into U-Boot, but it's a good point that the compiler treats it in strange ways. One alternative here would be to always call __builtin_alloca... This would probably have other issues though.
Third, the man page says:
NOTES
The alloca() function is machine- and compiler-dependent. For certain applications, its use can improve efficiency compared to the use of malloc(3) plus free(3). In certain cases, it can also simplify memory deallocation in applications that use longjmp(3) or siglongjmp(3). Otherwise, its use is discouraged.
In my opinion, U-Boot falls into the "otherwise" category...
Yup, and another man page in the "Bugs" section says:
The alloca() function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged.
Which seems even worse. So, OK, I think we've run this to the ground. And we can always find and replace all of the uses of Mikes macro easily if we think of something better later.
Thank you, Anton
I think I agree with this not being a great solution. I do wonder if it would be useful to consider a dedicated buffer management API that could be used to allocate and free cache line aligned power of two buffers. Perhaps something like a buddy heap for simplicity.
The longer I read this thread, the less frightening Mikes's macro becomes (compared tho the alternatives).
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "Though a program be but three lines long, someday it will have to be maintained."
- The Tao of Programming