5 ms·

When I read "Platform" I thought the article would be about CPU architectures. Still a good read though.

Danieru 12y ago
I'm not sure if this is standard terminology but I like to refer to multiple operating systems as cross-platform and multiple CPU architectures sets as cross-architecture. It looks like the author is doing something similar. After all the problems you encounter porting from Unix to Windows are different from what you hit porting across architectures. With cross-platform you're worrying over file IO functions or the lack of fork equivalent. With cross-architecture you must ensure the code is not abusing ints for storing pointers or assuming sizes of primitives.
- jacquesm 12y ago
  > With cross-architecture you must ensure the code is not abusing ints for storing pointers or assuming sizes of primitives. You should ensure that anyway, even when you're working on a single architecture. Those are very bad habits to form.
  - voltagex_ 12y ago
    I'm just starting C, what should I be using instead?
    - jacquesm 12y ago
      Don't make any assumptions about the architecture that your program will run on. If you have to go into variables with a different type than the one with which they were declared make sure you do so in a portable way. So, for instance, if you want the lower 8 bits of an int don't declare a pointer to a character and then lift out the byte, but do (value & 0xff) instead. That way if you move your program to a big endian machine it will still work. Storing pointers in ints assumes that pointers and ints are the same size, which is definitely not always the case. So store pointers in a space sizeof(whatevertype*) rather than sizeof(int).
    - mikeash 12y ago
      If you need to store a pointer in a integer variable, first stop and look very hard at what you're doing and think about whether you really need this. It's usually a really, really, really bad idea. If you have decided that you do really need it, then use the standard C type for "integer type large enough to hold a pointer". Yes, there is one. Actually two. They're called intptr_t and uintptr_t depending on whether you want signed or unsigned. Similarly, if you subtract two pointers and need to store the answer (this is less of a cause for reflection, but still not too common) then don't toss it into an int and hope that it works. Use the language-provided type for "difference of two pointers", ptrdiff_t. If you have a value that needs 32 bits of storage, don't throw it in an int and say, hey, int is probably at least 32 bits. Use the language-provided types int32_t and uint32_t. Understand what types are provided (Wikipedia has a decent summary at http://en.wikipedia.org/wiki/C_data_types http://en.wikipedia.org/wiki/C_data_types), what they mean, and what the guarantees are. Don't fall into the trap of "it works for me, here, now, so it's fine". If you need a particular guarantee (such as the ability to hold a certain range of numbers), ensure that the type you're using provides it.

I'm not sure if this is standard terminology but I like to refer to multiple operating systems as cross-platform and multiple CPU architectures sets as cross-architecture. It looks like the author is doing something similar. After all the problems you encounter porting from Unix to Windows are different from what you hit porting across architectures. With cross-platform you're worrying over file IO functions or the lack of fork equivalent. With cross-architecture you must ensure the code is not abusing ints for storing pointers or assuming sizes of primitives.

jacquesm 12y ago
> With cross-architecture you must ensure the code is not abusing ints for storing pointers or assuming sizes of primitives. You should ensure that anyway, even when you're working on a single architecture. Those are very bad habits to form.
- voltagex_ 12y ago
  I'm just starting C, what should I be using instead?
  - jacquesm 12y ago
    Don't make any assumptions about the architecture that your program will run on. If you have to go into variables with a different type than the one with which they were declared make sure you do so in a portable way. So, for instance, if you want the lower 8 bits of an int don't declare a pointer to a character and then lift out the byte, but do (value & 0xff) instead. That way if you move your program to a big endian machine it will still work. Storing pointers in ints assumes that pointers and ints are the same size, which is definitely not always the case. So store pointers in a space sizeof(whatevertype*) rather than sizeof(int).
  - mikeash 12y ago
    If you need to store a pointer in a integer variable, first stop and look very hard at what you're doing and think about whether you really need this. It's usually a really, really, really bad idea. If you have decided that you do really need it, then use the standard C type for "integer type large enough to hold a pointer". Yes, there is one. Actually two. They're called intptr_t and uintptr_t depending on whether you want signed or unsigned. Similarly, if you subtract two pointers and need to store the answer (this is less of a cause for reflection, but still not too common) then don't toss it into an int and hope that it works. Use the language-provided type for "difference of two pointers", ptrdiff_t. If you have a value that needs 32 bits of storage, don't throw it in an int and say, hey, int is probably at least 32 bits. Use the language-provided types int32_t and uint32_t. Understand what types are provided (Wikipedia has a decent summary at http://en.wikipedia.org/wiki/C_data_types http://en.wikipedia.org/wiki/C_data_types), what they mean, and what the guarantees are. Don't fall into the trap of "it works for me, here, now, so it's fine". If you need a particular guarantee (such as the ability to hold a certain range of numbers), ensure that the type you're using provides it.