5 ms·

char isn't fixed width. It is guaranteed to be at least 8-bits wide, but on a SHARC chip it is 32-bits wide. > The thing is, I assume all uintX types to really

char isn't fixed width. It is guaranteed to be at least 8-bits wide, but on a SHARC chip it is 32-bits wide. > The thing is, I assume all uintX types to really mean at least X bits wide. I am aware that the compiler is free to use its discretion for allocating memory. I worry about finer details only when I need to. That is explicitly not what they are. The standard is very clear that they must be exactly X bits wide, and if there is no type that is exactly X bits wide (and 2s compliment) then the types must not exist. But, if this is how you are treating these types, then aren't you basically just saying that in your mind you aren't using fixed width types? If everywhere you write uintX_t you are thinking "a type that is at least X bits wide", then you have to do all the reasoning as if the type is of an unknown width. It sounds like you have the worst of both worlds - the lack of portability of fixed width types combined with the slipperiness of minimum width types.

lake99 10y ago
This miscommunication was my fault. 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. This is also the reason we are not allowed to do arithmetic on chars. The types we use may eventually get typedefed to a char, but at least when I see someone else's function that requires a char as opposed to uint8, I know he's dealing with actual characters. > then you have to do all the reasoning as if the type is of an unknown width Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing.
- rkeene2 10y ago
  Why not uint_{least,fast}{8,16,32,64}_t ?
  - lake99 10y ago
    These are good, but some of our codebases predate these conventions. We don't even use // for commenting, because the code could find its way to a compiler that can't handle C99. Secondly, the overriding principle here is that the massive company, despite dealing with a huge variety of architectures, has to speak one language. If I were to start a company today in a similar domain, and not have a legacy to deal with, I would mandate uint_{least,fast}{8,16,32,64}_t and such.
- TheNewAndy 10y ago
  If that is the case, then it sounds like this whole thread has been miscommunication :-) The very start of this was talking about how fixed width types are not particularly helpful. I was under the impression that you were making the case for fixed width types, but it sounds like we've all been on the same side the whole time. > Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing. Exactly - if you are writing portable maths routines for your int16 type (i.e. a type which is at least 16-bits wide), then you do the analysis as if the type is exactly 16-bits wide. However, it might be that the type is actually 32-bits wide, and that doesn't change things.
  - lake99 10y ago
    > If that is the case, then it sounds like this whole thread has been miscommunication :-) 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. And I still advocate using the smallest (explicitly sized) type you could get away with. Weren't you advocating using bare C types (unsigned char, short, long, etc.) for your variables all along?
    - TheNewAndy 10y ago
      > 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

This miscommunication was my fault. 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. This is also the reason we are not allowed to do arithmetic on chars. The types we use may eventually get typedefed to a char, but at least when I see someone else's function that requires a char as opposed to uint8, I know he's dealing with actual characters. > then you have to do all the reasoning as if the type is of an unknown width Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing.

rkeene2 10y ago
Why not uint_{least,fast}{8,16,32,64}_t ?
- lake99 10y ago
  These are good, but some of our codebases predate these conventions. We don't even use // for commenting, because the code could find its way to a compiler that can't handle C99. Secondly, the overriding principle here is that the massive company, despite dealing with a huge variety of architectures, has to speak one language. If I were to start a company today in a similar domain, and not have a legacy to deal with, I would mandate uint_{least,fast}{8,16,32,64}_t and such.
TheNewAndy 10y ago
If that is the case, then it sounds like this whole thread has been miscommunication :-) The very start of this was talking about how fixed width types are not particularly helpful. I was under the impression that you were making the case for fixed width types, but it sounds like we've all been on the same side the whole time. > Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing. Exactly - if you are writing portable maths routines for your int16 type (i.e. a type which is at least 16-bits wide), then you do the analysis as if the type is exactly 16-bits wide. However, it might be that the type is actually 32-bits wide, and that doesn't change things.
- lake99 10y ago
  > If that is the case, then it sounds like this whole thread has been miscommunication :-) 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. And I still advocate using the smallest (explicitly sized) type you could get away with. Weren't you advocating using bare C types (unsigned char, short, long, etc.) for your variables all along?
  - TheNewAndy 10y ago
    > 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.