Hacker News Reader

Comment by haberman | Hacker News Reader

> Actually, casts to/from char * are always defined in C (chars are always assumed to alias).

Not true. The standard says you can access any object's value via the char type, but not the reverse. You can't cast a character array to any type and dereference it.

> The author was talking about "chunking" non-char units.

Sure, but you can call my copy_8_bytes() function like so legally:

    int64_t a, b = 0;
    copy_8_bytes(&a, &b);

So what I said applies to non-char types.

View on HN

> You can't cast a character array to any type and dereference it.

So making your own malloc backed by a static char array is undefined behavior?

Yes, I believe it would be. That's a good point, now that you mention it -- I have code that does just that, and I hadn't realized it's probably undefined.

The "effective type" (this is a term defined in the standard) of the char array elements would be "char", whereas the memory returned from malloc() is considered to be an object that initially has no effective type. I don't know of any way to take the char array and "erase" its effective type so that it can be used generically, like the value returned from malloc().

This is a problem!

This is one reason among many why people who write serious low-level code (e.g. game developers) think all the new aliasing rules are completely bonkers.

We implement our own allocators all the time. If you can't even do such a basic thing legally, then the rules are obvious nonsense.

Did you even make sure the memory was aligned?

Non-allocated memory (stack char) cannot be used like that. I'm sure you know alloc(), and malloc() is fast for small sizes.

> Did you even make sure the memory was aligned?

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.

> 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.

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.

Ok, what's wrong with alloca? Other than blowing the stack, that is.

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.

"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.

Reply on news.ycombinator.com