Re:The Strict Aliasing Situation Is Pretty Bad
by vc98mvco on Tuesday March 15, 2016 @12:08PM
(#11290654)
>
Just making sure. Fix that code will you! :)
> Yes, alloca. (Don't use it.)
> Just make a fast allocator that uses heap instead of the stack. You only need to malloc once and it can be used for any type since like you pointed out, it's effective type can be changed.
Re:The Strict Aliasing Situation Is Pretty Bad
by TorKlingberg on Tuesday March 15, 2016 @12:26PM
(#11290808)
Sometimes, especially in embedded systems, it is useful to have a bunch of statically allocated heaps. You can see them in a memory map, and the linker will tell you if they don't fit in memory.
There is also the case where you have some raw data from a file or network, that you want to re-interpret as a struct. That is always dangerous with endianness and struct padding, but it is a very common practice. You could always memcpy from a char array to a struct, but that can waste memory.
Re:The Strict Aliasing Situation Is Pretty Bad
by mcguire on Tuesday March 15, 2016 @04:05PM
(#11292562)
Ok, what's wrong with alloca? Other than blowing the stack, that is.
Re:The Strict Aliasing Situation Is Pretty Bad
by haberman on Tuesday March 15, 2016 @06:00PM
(#11293353)
See: https://google.github.io/styleguide/cppguide.html#Variable-L...
At least that's the rationale for why we don't use it at Google.
Re:The Strict Aliasing Situation Is Pretty Bad
by mcguire on Thursday March 17, 2016 @11:56AM
(#11305159)
"More importantly, they allocate a data-dependent amount of stack space that can trigger difficult-to-find memory overwriting bugs: "It ran fine on my machine, but dies mysteriously in production"."
Yep, blowing the stack will do that.
Of course, what do you take me for? :)
> I'm sure you know alloc()
Do you mean alloca? It has a lot of problems, and is generally prohibited at Google.
> and malloc() is fast for small sizes.
Not nearly fast enough for my purposes.