3 ms·

> The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or crea

> The only way to ensure fixed widths without int_leastX conventions is to be intimately familiar with the platform while we are declaring our typedefs, or creating makefiles for our projects.. int_leastX_t doesn't give you fixed width types - that's the entire point of them. They are not fixed width. > And to that extent, we use only fixed with types. I don't get it. You said this: > We don't use uint8_t or other such things, we use uint8, uint16, etc. These are typedefed to compiler-specific types that guarantee a required minimum size. You are using uint_least8_t, uint_least16_t, just with different names. As I've said - I don't really care what things are called. Semantically, there is very little that is different between "uint_least16_t" and "unsigned short".

lake99 10y ago
> As I've said - I don't really care what things are called. I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter. > Semantically, there is very little that is different between "uint_least16_t" and "unsigned short". But there could be a difference between "uint_least16_t" and "unsigned int" or "unsigned short". And there could be a difference between "uint_least32_t" and "unsigned int" or "unsigned long".
- TheNewAndy 10y ago
  The comment that started it all was very clear that "make a decision as to the width of an integer" was referring to deciding on the exact width. In the same sentence that quote is taken from, it makes it clear that it is talking about fixed sized numerics. Deciding the width of an integer is not the same as deciding the minimum width of an integer (otherwise, the original comment makes no sense). In the next paragraph it contrasts this with the minimum width approach ("word-sized ints and size_t's"). Deciding on the minimum width of a data type is a decision that needs to be made, and is made regardless of how you spell your type name. If you use an "int", you have specified that it must be at least 16-bits wide. Just because the name of the type doesn't have the number 16 in it doesn't mean that the same decision isn't being made.
  - lake99 10y ago
    I lost track of this discussion! > If you use an "int", you have specified that it must be at least 16-bits wide. Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on. A developer is obliged to do that, but system integrators and cross-team reviewers are in for a world of pain if they have to keep reading across code bases across platforms like that. It's not an unrealistic scenario. A modern airplane or electric train is bound to have tens of processor families littered throughout the vehicle. The original commenter also wrote about Swift going backwards, with its UInt8, Int32, etc. I'm not a Swift programer, but the documents gave me the impression that these are, again, syntactic widths, not physically allocated, i.e. semantic widths. All this shows that the original commenter had a problem with specifing any indication of the size of integers. His emphasis on "word-sized" clearly indicates that he wants to use "int" everywhere, and hopes the compiler will take care of the rest. This is what Swift does too with its "Int".
    - TheNewAndy 10y ago
      > I lost track of this discussion! Hah, me too. I wonder if you will ever see this :-) > Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. If people are just writing code for PCs, then it is no longer portable code that is being talked about. But when writing portable code, which you do and I do, being overly specific with type widths is bad. The C data types all have very specific widths, and it is just a fact that int is at least 16-bits wide. I'm not a swift person either, but based on reading this: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html https://developer.apple.com/library/content/documentation/Sw... It sounds like the types with numbers in their name are most certainly fixed width types. The original commenter didn't like the emphasis on such fixed widths, and I think the swift language designers agree - their section on the "Int" type (which is at least 32-bits wide, but may be 64-bits wide) says that this is the type that people should be using generally. "Int" in swift is quite similar to "int" in C, just the C version is less constrained (may be any width >= 16 bits). But the principle is the same - for better portable code, enforcing exact widths of types is not a good thing.

lake99 10y ago

> As I've said - I don't really care what things are called. I think this is where our disagreement lies. To me, this counts as "make a decision as to the width of an integer every time I declare a function". We are deciding the lower bound, but still, it's a decision on that matter. > Semantically, there is very little that is different between "uint_least16_t" and "unsigned short". But there could be a difference between "uint_least16_t" and "unsigned int" or "unsigned short". And there could be a difference between "uint_least32_t" and "unsigned int" or "unsigned long".

TheNewAndy 10y ago
The comment that started it all was very clear that "make a decision as to the width of an integer" was referring to deciding on the exact width. In the same sentence that quote is taken from, it makes it clear that it is talking about fixed sized numerics. Deciding the width of an integer is not the same as deciding the minimum width of an integer (otherwise, the original comment makes no sense). In the next paragraph it contrasts this with the minimum width approach ("word-sized ints and size_t's"). Deciding on the minimum width of a data type is a decision that needs to be made, and is made regardless of how you spell your type name. If you use an "int", you have specified that it must be at least 16-bits wide. Just because the name of the type doesn't have the number 16 in it doesn't mean that the same decision isn't being made.
- lake99 10y ago
  I lost track of this discussion! > If you use an "int", you have specified that it must be at least 16-bits wide. Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on. A developer is obliged to do that, but system integrators and cross-team reviewers are in for a world of pain if they have to keep reading across code bases across platforms like that. It's not an unrealistic scenario. A modern airplane or electric train is bound to have tens of processor families littered throughout the vehicle. The original commenter also wrote about Swift going backwards, with its UInt8, Int32, etc. I'm not a Swift programer, but the documents gave me the impression that these are, again, syntactic widths, not physically allocated, i.e. semantic widths. All this shows that the original commenter had a problem with specifing any indication of the size of integers. His emphasis on "word-sized" clearly indicates that he wants to use "int" everywhere, and hopes the compiler will take care of the rest. This is what Swift does too with its "Int".
  - TheNewAndy 10y ago
    > I lost track of this discussion! Hah, me too. I wonder if you will ever see this :-) > Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. If people are just writing code for PCs, then it is no longer portable code that is being talked about. But when writing portable code, which you do and I do, being overly specific with type widths is bad. The C data types all have very specific widths, and it is just a fact that int is at least 16-bits wide. I'm not a swift person either, but based on reading this: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html https://developer.apple.com/library/content/documentation/Sw... It sounds like the types with numbers in their name are most certainly fixed width types. The original commenter didn't like the emphasis on such fixed widths, and I think the swift language designers agree - their section on the "Int" type (which is at least 32-bits wide, but may be 64-bits wide) says that this is the type that people should be using generally. "Int" in swift is quite similar to "int" in C, just the C version is less constrained (may be any width >= 16 bits). But the principle is the same - for better portable code, enforcing exact widths of types is not a good thing.