Earlier quoted context omitted.
Not quite, (void *) is special in this regard IIRC, specifically for cases like this. It's a valid pointer but you're required to ensure that any platform requirements like alignment and size will match the requirements of what you're doing.
No, (void⁎) is not special in this way. It just makes things look nicer. The code also isn't undefined behavior... but you are really asking to hit compiler bugs! This is an easy way to confuse gcc into wrongly determining that the code has undefined behavior, and if gcc gets confused then it may determine that a code path can't be taken. Code paths that can't be taken may be deleted. The main rule here is that memor…
Memory Allocators 101 – Write a simple memory allocator (2016)
51–56 of 56 posts
Re: Memory Allocators 101 – Write a simple memory allocator (2016)
#52Good timing. I literally had to do this on a whiteboard in an interview about 11 hours ago. Interesting things to consider: Fragmentation prevention, real-time performance, minimizing locking(lock-free techniques, or per-thread free lists), and reusing the freed memory to contain the free list structure. I basically started out whiteboarding what the article lays out and by the end of the interview realized everythin…
If I may ask, what position/designation you were interviewing for?
Re: Memory Allocators 101 – Write a simple memory allocator (2016)
#53Re: Memory Allocators 101 – Write a simple memory allocator (2016)
#54Earlier quoted context omitted.
So I suppose that header = (struct header_t*)(block - 1); would be UB then.
Haven't read the article but if block is void *, this won't compile because sizeof(void) is not defined. And they are probably trying to subtract the sizeof(struct header) hence the expression in your original comment.
Re: Memory Allocators 101 – Write a simple memory allocator (2016)
#55Earlier quoted context omitted.
The moment you call sbrk or mmap, you're outside of standard C, so no. Treating a pointer as an integer in order to mess with the bits is also a violation. Aside from that, the style used here is probably OK. It is hard to say what exactly would trigger the gcc bugs, but I'm pretty sure that a recent gcc would be OK for this code.
> Treating a pointer as an integer in order to mess with the bits is also a violation. Violation of what exactly? Converting a pointer to an integer, and vice versa, is implementation defined. As long as you're not trying to write implementation-independent code, it's perfectly fine.