Hacker News Reader

Comment by jheriko | Hacker News Reader

That packing the controller id into a pointer, which you couldn't use to point at a controller id because it gets freed before you can use it?

I must misunderstand something because the hack is going to fail too, except that you are going to end up with some controller id in your allocator's free list or some other such nonsense...

That last one is best. After having to struggle and fight for 640k for /the heart of a renderer/ if someone had left 2MB lying around that would have been great. Then again so would not using loads of memory for all sorts of weird and wonderful things that are much less important... like C struct padding, or making everything into memory pools, before you have any memory problems. :)

View on HN

You'd probably only need two or three bits to pack a controller id. Depending on how much memory the system has, and and things like data alignment, you can find some bits in the pointer that will always have a specific value (say, zero). Then, you can store the ID in those bits, and mask them away when you actually want the pointer.

Edit: You probably shouldn't do this in new code, but in the context of memory-constrained C code it's a nice hack.

Interesting enough, the current 64-bit ObjC runtime does something similar, with so-called "tagged pointers".

https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

right, but then why can't you take that same opportunity to pull your pointer out and replace it with a zero to avoid it being free'd ?

re: controller id into a pointer

If I understood correctly, the pointer is just a field in a common struct (common in event-handling code). As he mentions, it's usually used to point to extra data that you allocated separately in case you need it for that specific type of event, but what if you're having trouble with allocation and your data conveniently fits in the pointer field itself? So he just cast his controller id into the unused pointer parameter. He's not mangling any allocator data.

Which, if you're not going to use that pointer parameter otherwise, I think is perfectly sensible (and as long as you don't have code along the line of if (ptr != NULL) free(ptr);). I do it all the time... cough. For example, when creating a thread, you can pass it a void* to some data for it. I just cast a threadID integer into there. Hell, you'll see just that in the first example on a google search for "pthread example"!

Apparently there was top level code (that couldn't be changed as it was needed several other places) that DID free the pointer though...

hopefully the controller id was just the lowest bit or two, which would then align back to zero or something when it came time to free ;-)

yeah, so he said the problem was that this pointer was freed out of his control. any way of packing data into that pointer suffers the same problem - except even worse, you are now freeing something that wasn't allocated.

The pointer would get freed later, but freeing a pointer does not change the pointer address. Eg: If the pointer is storing the address "10" and you free 10, the value 10 is not lost, the value 10 points to gets freed though.

Assuming the controller ID would normally point to somewhere in protected memory, the frees would have no effect, and he could store the controller ID in the pointer parameter as the address of the pointer.

But the problem would be attempting to free the pointer which points to some random memory location (the address "10") - I'd expect it to end with a segfault with a high probability.

i've not yet worked on a game console platform that doesn't end up in trouble when you try and free some small number. given the context of doom 3 engine i think my experience covers it well... unless they did some insane PS1 port for reasons unknown.

maybe they used a custom allocator though... its very common.

Reply on news.ycombinator.com