3 ms·

Can someone explain what is the horrible to pack an integer into void* pointer? A void pointer takes 4~8bytes, an integer takes no more than 4 bytes. As long as

by liuliu 17y ago

Can someone explain what is the horrible to pack an integer into void* pointer? A void pointer takes 4~8bytes, an integer takes no more than 4 bytes. As long as the program don't passing value from little-endian to big-endian system, it should be all fine except the semantic meaning?

swolchok 17y ago
It's not guaranteed by the language that pointers are as big as or bigger than integers. Some architecture somewhere might die horribly on this. comp.lang.c FAQ on this: http://c-faq.com/ptrs/int2ptr.html http://c-faq.com/ptrs/int2ptr.html
- jwilliams 17y ago
  You're right -- the general rule is that ints and ptrs shouldn't be interchanged. However -- In this case, it's likely the number of integers required (controller ids, which I guess might be 1 to 4?) would fit in almost any ptr you can think of. Conversions aren't guaranteed, but if you copy/pack it yourself there shouldn't be a problem -- e.g. do a memcpy of one byte. More likely the author was pointing at the fact that this value was later 'free'd' by the event loop. Which is fairly nasty.
  - grsxfcyt 17y ago
    The general rule is that you shouldn't go free-ing memory you didn't allocate. I had one colleague who would insist on trying to free FILE* after he had closed the file.
jerf 17y ago
The primary problem from my point of view is that something, somewhere, deep in your system in an unexamined code path, will actually try to dereference your not-NULL pointer. Something you didn't QA and only happens in the field, or after a certain date, or since IIRC we're talking about wireless controllers, only happens when the local Wifi is on channel 11, or... the perversity of the real world can not be underestimated. In this case, issues of pointer size are irrelevant since I think the target was a specific console, but of course that's still "dirty".
deleted 17y ago
[deleted]
wvenable 17y ago
Well, lets not forget there's still that free() call which will try and free the integer value packed into the pointer.

by liuliu 17y ago

swolchok 17y ago

It's not guaranteed by the language that pointers are as big as or bigger than integers. Some architecture somewhere might die horribly on this. comp.lang.c FAQ on this: http://c-faq.com/ptrs/int2ptr.html http://c-faq.com/ptrs/int2ptr.html

jwilliams 17y ago
You're right -- the general rule is that ints and ptrs shouldn't be interchanged. However -- In this case, it's likely the number of integers required (controller ids, which I guess might be 1 to 4?) would fit in almost any ptr you can think of. Conversions aren't guaranteed, but if you copy/pack it yourself there shouldn't be a problem -- e.g. do a memcpy of one byte. More likely the author was pointing at the fact that this value was later 'free'd' by the event loop. Which is fairly nasty.
- grsxfcyt 17y ago
  The general rule is that you shouldn't go free-ing memory you didn't allocate. I had one colleague who would insist on trying to free FILE* after he had closed the file.

jerf 17y ago

The primary problem from my point of view is that something, somewhere, deep in your system in an unexamined code path, will actually try to dereference your not-NULL pointer. Something you didn't QA and only happens in the field, or after a certain date, or since IIRC we're talking about wireless controllers, only happens when the local Wifi is on channel 11, or... the perversity of the real world can not be underestimated. In this case, issues of pointer size are irrelevant since I think the target was a specific console, but of course that's still "dirty".

deleted 17y ago

[deleted]

wvenable 17y ago

Well, lets not forget there's still that free() call which will try and free the integer value packed into the pointer.