4 ms·

[u]intN_t may not exist. If you are working with arrays, always use size_t if not, use [u]int_leastN_t in 99% of the cases, except if you are working with netw

[u]intN_t may not exist. If you are working with arrays, always use size_t if not, use [u]int_leastN_t in 99% of the cases, except if you are working with network protocols, [u]intN_t is a bad choice

bluetomcat 11y ago
What if your array is never going to be larger than, say, UINT8_MAX, and you need to pack thousands of these "sizes" into an array of structs? Using an 8-byte size_t in that case will inflate the cache usage significantly.
- annathebannana 11y ago
  If you are sure that this is going to be the case, then use uint_least8_t.
Nursie 11y ago
>> [u]intN_t may not exist. It will, that's guaranteed by the standard. If it's not a standards compliant compiler/runtime/platform, you've got bigger problems. >> If you are working with arrays, always use size_t if not, use [u]int_leastN_t Sure, on array indices, size_t is appropriate. I can't see an advantage in using 'least' as standards dictate that 8/16/32/64 bit types are available. >> in 99% of the cases, except if you are working with network protocols, [u]intN_t is a bad choice No, it's the best choice in most cases because it makes the code a little more explicit and easier to understand, and it makes developers think about the range of the data you're using.
- exprI 11y ago
  >It will, that's guaranteed by the standard. If it's not a standards compliant compiler/runtime/platform, you've got bigger problems. No it isn't. It's a bad practice citing something you didn't read. Standard compliance can be achieved on platforms without native 8-, 16-, 32- or 64-bit integers (signed and/or unsigned), and you need not simulate such integers in software, which is why all the (u)intN_t types are optional.
- to3m 11y ago
  The sized types are optional, since they are more restrictive than the ordinary types - see section 7.20.1.1 in the standard (http://port70.net/~nsz/c/c11/n1570.html#7.20.1.1 http://port70.net/~nsz/c/c11/n1570.html#7.20.1.1). To summarize: intN_t is exactly N bits, with zero padding bits, and 1 2's complement sign bit; uintN_t is exactly N bits, with zero padding bits; the implementation must provide such typedefs for all such types it supports. So, if a system is 1's complement, you won't get the intN_t types at all. If the system doesn't support a particular bit width, you won't get the types for that width.
  - bsder 11y ago
    > So, if a system is 1's complement As someone who actually programmed a 1's complement system with end-around carry, I'm going to call you out on this. What system still exists that can run C99 and is one's complement?
    - to3m 11y ago
      I am playing the language lawyer game - there is nothing to call out. Is what I say justified by the standard? Yes, or no? There are no other issues involved ;) I have no idea if C99 runs on any 1's complement systems. I don't know what end-around carry is. I don't care what it is. I don't care about any of this 1's complement nonsense. But the standard says it exists, and must be taken into account, and, therefore, by the rules of the game, I am obliged to assume these things.

[u]intN_t may not exist. If you are working with arrays, always use size_t if not, use [u]int_leastN_t in 99% of the cases, except if you are working with network protocols, [u]intN_t is a bad choice

bluetomcat 11y ago

What if your array is never going to be larger than, say, UINT8_MAX, and you need to pack thousands of these "sizes" into an array of structs? Using an 8-byte size_t in that case will inflate the cache usage significantly.

annathebannana 11y ago
If you are sure that this is going to be the case, then use uint_least8_t.

Nursie 11y ago

>> [u]intN_t may not exist. It will, that's guaranteed by the standard. If it's not a standards compliant compiler/runtime/platform, you've got bigger problems. >> If you are working with arrays, always use size_t if not, use [u]int_leastN_t Sure, on array indices, size_t is appropriate. I can't see an advantage in using 'least' as standards dictate that 8/16/32/64 bit types are available. >> in 99% of the cases, except if you are working with network protocols, [u]intN_t is a bad choice No, it's the best choice in most cases because it makes the code a little more explicit and easier to understand, and it makes developers think about the range of the data you're using.

exprI 11y ago
>It will, that's guaranteed by the standard. If it's not a standards compliant compiler/runtime/platform, you've got bigger problems. No it isn't. It's a bad practice citing something you didn't read. Standard compliance can be achieved on platforms without native 8-, 16-, 32- or 64-bit integers (signed and/or unsigned), and you need not simulate such integers in software, which is why all the (u)intN_t types are optional.
to3m 11y ago
The sized types are optional, since they are more restrictive than the ordinary types - see section 7.20.1.1 in the standard (http://port70.net/~nsz/c/c11/n1570.html#7.20.1.1 http://port70.net/~nsz/c/c11/n1570.html#7.20.1.1). To summarize: intN_t is exactly N bits, with zero padding bits, and 1 2's complement sign bit; uintN_t is exactly N bits, with zero padding bits; the implementation must provide such typedefs for all such types it supports. So, if a system is 1's complement, you won't get the intN_t types at all. If the system doesn't support a particular bit width, you won't get the types for that width.
- bsder 11y ago
  > So, if a system is 1's complement As someone who actually programmed a 1's complement system with end-around carry, I'm going to call you out on this. What system still exists that can run C99 and is one's complement?
  - to3m 11y ago
    I am playing the language lawyer game - there is nothing to call out. Is what I say justified by the standard? Yes, or no? There are no other issues involved ;) I have no idea if C99 runs on any 1's complement systems. I don't know what end-around carry is. I don't care what it is. I don't care about any of this 1's complement nonsense. But the standard says it exists, and must be taken into account, and, therefore, by the rules of the game, I am obliged to assume these things.