7 ms·

Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also b

by lake99 10y ago

Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work. > Notice how smooth the 32-bit to 64-bit transition went? There are many reasons for that. For most PC work, a 32-bit int is more than large enough. Going to 64-bit should not have affected that at all. When you're working with embedded systems, you're often working at sizes that are the bare minimum that you can live with. You might also get to work on architectures where char, short, and int are all 32-bit wide. Assume something, and the communications protocol stops working. Moreover, the PC architecture itself supported coexistence of 32-bit and 64-bit executables.

mieko 10y ago
> Looks like you haven't worked on embedded systems. I've deleted a defensive technical response to point out that these dismissive assumptions (usually unjustified) are pretty prevalent on HN, and I don't think it promotes level-headed discussion. It reads like "Let me discredit a stranger's background that I don't know, and then argue my opposing view." It creates a defensive mindset off the bat. Edit: I mean, your points are valid. We won't agree on them, but I don't like the assumption that we won't agree because I'm ignorant to them.
- wott 10y ago
  You shouldn't have worried: his points are not valid at all. Using fixed-width types across various embedded (as in "small and exotic") platforms is a nightmare for portability. There is no reason not to use standard integer types, providing you understood their definition. Use fixed-width types only when absolutely really needed; don't use standard types when you need fixed-width width, assuming they will be an exact size, and everything will be fine.
TheNewAndy 10y ago
I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. You have an int16_t? How do you port it to a machine without a 16-bit type? What would happen if you replaced it with a 32-bit type? If you are relying on wraparound, then your code is already undefined, so some compiler is likely going to mess with you anyway. The stuff about communicating with the outside world is quite different. At this point you have protocols, and it depends on how a protocol is written, and how you are able to actually interact with the world to fulfil that protocol. If the protocol is an ABI, then generally you are fine, because the compiler too will match the ABI. If it is a file format, then you need to know how your file io functions work (do they just write the bottom 8-bits of a char, or do they blat the whole thing across?).
- lake99 10y ago
  > How do you port it to a machine without a 16-bit type? The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating. > The stuff about communicating with the outside world is quite different. I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is 29 bits. What generic "int" would you use when you want to fill in this identifier? And no, I work at a level that's lower than an ABI. So, no OS, no file IO, etc.
  - adrianN 10y ago
    How does it make portability worse if you write your code in a way that doesn't assume anything about the size of your ints? If you don't know that your ints are 16 or 32 or 27 bits long you have to be more careful with checking for overflows, but if the code does that I don't see what problems you'll have when you port it to a platform with a different int size.
    - lake99 10y ago
      You can only check for overflows if you err in favour of larger architectures and declare all integers as "long int", and then check for overflows. Even the 8-bit compilers I have seen will allocate 32-bits for long int. And doing that will let the code remain compatible on smaller architectures, but it will hammer your CPU and memory usage. It's not a pleasant situation when you're struggling to save bytes.
      - TheNewAndy 10y ago
        You can't ever check for (signed) overflows in C - you can only prevent them. I'm not sure if I'm drawing a distinction you weren't intending to make (if so, then my apologies). When you are adding signed integers in C, you need to prove that doing so can't overflow - knowing the exact width doesn't really help you here - just prove it for the narrowest possible width and you have proved it for all of them. In practice this isn't hard because either it is trivial to prove (e.g. incrementing a variable which is known to be small, or just plain modifying the code to put in explicit saturation/other logic for the cases where things get hairy) Of course an 8-bit compiler is going to allocate 32-bits for a long int - the language requires that a long is at least 32-bits wide. If you had a compiler that didn't do this, then it isn't a C compiler.
raverbashing 10y ago
You're not wrong, but it seems you're not abstracting enough (and depends on your embedded system) However the smaller they are the less complex the system is. And running higher level languages is not as taboo today

by lake99 10y ago

mieko 10y ago

> Looks like you haven't worked on embedded systems. I've deleted a defensive technical response to point out that these dismissive assumptions (usually unjustified) are pretty prevalent on HN, and I don't think it promotes level-headed discussion. It reads like "Let me discredit a stranger's background that I don't know, and then argue my opposing view." It creates a defensive mindset off the bat. Edit: I mean, your points are valid. We won't agree on them, but I don't like the assumption that we won't agree because I'm ignorant to them.

wott 10y ago
You shouldn't have worried: his points are not valid at all. Using fixed-width types across various embedded (as in "small and exotic") platforms is a nightmare for portability. There is no reason not to use standard integer types, providing you understood their definition. Use fixed-width types only when absolutely really needed; don't use standard types when you need fixed-width width, assuming they will be an exact size, and everything will be fine.

TheNewAndy 10y ago

I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. You have an int16_t? How do you port it to a machine without a 16-bit type? What would happen if you replaced it with a 32-bit type? If you are relying on wraparound, then your code is already undefined, so some compiler is likely going to mess with you anyway. The stuff about communicating with the outside world is quite different. At this point you have protocols, and it depends on how a protocol is written, and how you are able to actually interact with the world to fulfil that protocol. If the protocol is an ABI, then generally you are fine, because the compiler too will match the ABI. If it is a file format, then you need to know how your file io functions work (do they just write the bottom 8-bits of a char, or do they blat the whole thing across?).

lake99 10y ago
> How do you port it to a machine without a 16-bit type? The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating. > The stuff about communicating with the outside world is quite different. I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is 29 bits. What generic "int" would you use when you want to fill in this identifier? And no, I work at a level that's lower than an ABI. So, no OS, no file IO, etc.
- adrianN 10y ago
  How does it make portability worse if you write your code in a way that doesn't assume anything about the size of your ints? If you don't know that your ints are 16 or 32 or 27 bits long you have to be more careful with checking for overflows, but if the code does that I don't see what problems you'll have when you port it to a platform with a different int size.
  - lake99 10y ago
    You can only check for overflows if you err in favour of larger architectures and declare all integers as "long int", and then check for overflows. Even the 8-bit compilers I have seen will allocate 32-bits for long int. And doing that will let the code remain compatible on smaller architectures, but it will hammer your CPU and memory usage. It's not a pleasant situation when you're struggling to save bytes.
    - TheNewAndy 10y ago
      You can't ever check for (signed) overflows in C - you can only prevent them. I'm not sure if I'm drawing a distinction you weren't intending to make (if so, then my apologies). When you are adding signed integers in C, you need to prove that doing so can't overflow - knowing the exact width doesn't really help you here - just prove it for the narrowest possible width and you have proved it for all of them. In practice this isn't hard because either it is trivial to prove (e.g. incrementing a variable which is known to be small, or just plain modifying the code to put in explicit saturation/other logic for the cases where things get hairy) Of course an 8-bit compiler is going to allocate 32-bits for a long int - the language requires that a long is at least 32-bits wide. If you had a compiler that didn't do this, then it isn't a C compiler.

raverbashing 10y ago

You're not wrong, but it seems you're not abstracting enough (and depends on your embedded system) However the smaller they are the less complex the system is. And running higher level languages is not as taboo today