This just isn't true -- code which is performance optimized to minimize its memory footprint or use the vector unit, or which relies on binary data loaded from disk in a fixed format can easily contain assumptions about pointer size, and these are entirely reasonable assumptions. This doesn't preclude boneheaded assumptions in some cases, but not all such assumptions are unwarranted.
Hey Programmer - I understand (barely) how somebody might optimize things to the point of assuming a pointer is 32-bit, but binary data loaded from disk? There's no way to actually read a pointer from disk. The only situation I can see that occuring in is if a program dumps an entire struct to disk and when reading in first reads in the struct then sets the pointers to good values. Of course, such code has bigger issues than 64-bit cleanliness (for starters, endianness).
Can you fill me in on a *reasonable* situation where pointer size would be hardcoded into a program? (Examples like those above and programs which hardcode the size of their data types don't count as reasonable.)
Hey Programmer - I understand (barely) how somebody might optimize things to the point of assuming a pointer is 32-bit, but binary data loaded from disk? There's no way to actually read a pointer from disk. The only situation I can see that occuring in is if a program dumps an entire struct to disk and when reading in first reads in the struct then sets the pointers to good values. Of course, such code has bigger issues than 64-bit cleanliness (for starters, endianness).
Can you fill me in on a *reasonable* situation where pointer size would be hardcoded into a program? (Examples like those above and programs which hardcode the size of their data types don't count as reasonable.)
Your first paragraph described the situation reasonably accurately. If you look at the ELF file format Linux uses you will see it has a pointer "fix-up" mechanism which patches the pointers after loading the block of data. Code is, therefore, the example you are looking for. The same technique is used when it is essential that data be able to load very quickly and use a minimum amount of memory. We do it all the time at work.
Comments
Originally posted by Programmer
This just isn't true -- code which is performance optimized to minimize its memory footprint or use the vector unit, or which relies on binary data loaded from disk in a fixed format can easily contain assumptions about pointer size, and these are entirely reasonable assumptions. This doesn't preclude boneheaded assumptions in some cases, but not all such assumptions are unwarranted.
Hey Programmer - I understand (barely) how somebody might optimize things to the point of assuming a pointer is 32-bit, but binary data loaded from disk? There's no way to actually read a pointer from disk. The only situation I can see that occuring in is if a program dumps an entire struct to disk and when reading in first reads in the struct then sets the pointers to good values. Of course, such code has bigger issues than 64-bit cleanliness (for starters, endianness).
Can you fill me in on a *reasonable* situation where pointer size would be hardcoded into a program? (Examples like those above and programs which hardcode the size of their data types don't count as reasonable.)
Originally posted by Anonymous Karma
Hey Programmer - I understand (barely) how somebody might optimize things to the point of assuming a pointer is 32-bit, but binary data loaded from disk? There's no way to actually read a pointer from disk. The only situation I can see that occuring in is if a program dumps an entire struct to disk and when reading in first reads in the struct then sets the pointers to good values. Of course, such code has bigger issues than 64-bit cleanliness (for starters, endianness).
Can you fill me in on a *reasonable* situation where pointer size would be hardcoded into a program? (Examples like those above and programs which hardcode the size of their data types don't count as reasonable.)
Your first paragraph described the situation reasonably accurately. If you look at the ELF file format Linux uses you will see it has a pointer "fix-up" mechanism which patches the pointers after loading the block of data. Code is, therefore, the example you are looking for.