6 ms·

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 misunders

by jheriko 12y ago

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

cbhl 12y ago
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.
- United857 12y ago
  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-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
- jheriko 12y ago
  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 ?
AceJohnny2 12y ago
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"!
- AmirS2 12y ago
  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 ;-)
- jheriko 12y ago
  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.
feelix 12y ago
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.
- kruczek 12y ago
  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.
- jheriko 12y ago
  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.

by jheriko 12y ago

cbhl 12y ago

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.

United857 12y ago
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-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
jheriko 12y ago
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 ?

AceJohnny2 12y ago

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

AmirS2 12y ago
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 ;-)
jheriko 12y ago
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.

feelix 12y ago

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.

kruczek 12y ago
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.
jheriko 12y ago
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.