3 ms·

> I am not sure about that. The original poster wrote 'I have never once thought: "You know what, I'd like to make a decision as to the width of an integer ever

> I am not sure about that. The original poster wrote 'I have never once thought: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function."' I disagreed with that, and that's where the whole discussion started off. But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. By doing that, you are saying that you don't care about the width of an integer, as long as it is at least N bits, which is exactly the right thing to do for portable code. > And I still advocate using the smallest (explicitly sized) type you could get away with. This is where I'm a little confused, if we go back: >> Would you suggest a uint29_t? > If you are aware of a machine that provides that, yes! Otherwise, I'd suggest uint32_t. Yes, If I understand what you are saying, then you are saying that at your work you use "intN" to mean "an integer of at least N bits". Every machine that has a C compiler for it has such a type - one possible type that could satisfy this is long. If you have a C99 compiler, then another type is int_least32_t. So from this, it sounded like you were talking about fixed width types. > Weren't you advocating using bare C types (unsigned char, short, long, etc.) for your variables all along? I've been advocating for non-fixed width types all along. How their names are spelt is a secondary thing and one where lots of people have different opinions which makes it hard to be black and white. However, the meanings of the words is what I care about, and so whenever I gave examples I would tend towards the C90 types because they have the right semantics (they are minimum width types of sensible sizes) and they are portable everywhere (how long has it taken for MS to have stdint.h in their C compiler?) and have definitions that can be expected to be known by any C programmer (since their definitions are part of the language definition of C). Personally, I think that the int_leastN_t types are ugly, so I avoid them (and it sounds like your company does too, since it renames them to less ugly (but I think more confusing) names). Although they are ugly, I do think their semantics are good enough to use for portable code. I wouldn't say the same about the fixed width types (since they may not exist) or the "fast" types (they aren't good for portability because their size is ambiguous across toolchains targeting the same ABI - compare the GNU definitions to the MSVS definitions). This paragraph is just my opinions, and I expect others to have differing opinions, and I don't really care. What I will hold to though is that fixed width types are bad for portability, and I think you agree with that.

lake99 10y ago
> But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. We declare the minimum width for all variables. We don't use "int" in for loops and hope for the best. I wouldn't go as far as to say "we don't care". We don't worry too much for code that's mean to be portable. We obviously care in non-portable code. But the important point here is that we use the same conventions whether we are writing portable code or not. > So from this, it sounded like you were talking about fixed width types. C99 conventions are too radically new to be used across our entire codebase. Uglyness has nothing to do with it. 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. And to that extent, we use only fixed with types.
- TheNewAndy 10y ago
  > 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".

lake99 10y ago

> But your solution also doesn't involve deciding on the width of an integer - your solution is to use integers that have a minimum width. We declare the minimum width for all variables. We don't use "int" in for loops and hope for the best. I wouldn't go as far as to say "we don't care". We don't worry too much for code that's mean to be portable. We obviously care in non-portable code. But the important point here is that we use the same conventions whether we are writing portable code or not. > So from this, it sounded like you were talking about fixed width types. C99 conventions are too radically new to be used across our entire codebase. Uglyness has nothing to do with it. 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. And to that extent, we use only fixed with types.

TheNewAndy 10y ago
> 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".