4 ms·

I did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I

by lake99 10y ago

I did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I checked in code where I do math on char. It has to be on uint8 or int8 (or other widths). Not that I'd ever check in such code, after all, I agree with the company policy there. But "char" is just a part of the problem. We have the same issue with all kinds of bid-widths. When I read PC code with such names, I don't worry about their sizes, and just assume i386 conventions. When I read embedded C code with datatypes of undeclared widths, I get quite annoyed. Thankfully, I can't recall the last time I read such code. > then uint_least32_t should make you happy 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.

deleted 10y ago
[deleted]
TheNewAndy 10y ago
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?

by lake99 10y ago

deleted 10y ago

[deleted]

TheNewAndy 10y ago

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?