4 ms·

Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portabil

by hazeii 7y ago

Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portability issues between 32 and 64 bit).

VonChair 7y ago
I think it's important to push forward with getting people out of bad habits. In a lot of cases, the only way to do that is to force it. I don't often agree with things Apple does, but their forcing people to use x64 is similar to this I think.
xscott 7y ago
The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argument to be had over size_t vs ssize_t, but that can wait :-)
- madmax96 7y ago
  Then there’s the perennial problem of missing format specifiers for POSIX types like pid_t. Although you could argue that POSIX should mandate macros to appropriately handle them, the root problem is the same. The default integer types have not aged well...
  - xscott 7y ago
    > missing format specifiers for POSIX types like pid_t This bothers me less because I can always cast it up: fprintf(logfile, "pid: %lld", (long long)pid); Technically not portable, but find a platform with PIDs where this breaks. You can count on long long being at least 64 bits, and I think it'll be a while before we need 128 bit process IDs. :-) > The default integer types have not aged well... To me, the real pisser is that every compiler copped out and decided to leave int at 32 bits when the architecture advanced to 64 bits. Part of the reason for compilers exploiting "signed can't overflow" is so they can work around for loops with 32 bit int variables, and this has ugly consequences because most of the conversion rules in C are defined with respect to int. And honestly, Microsoft should burn for leaving long at 32 bits.
    - jacobush 7y ago
      On Amiga, long was 32 bit and int 16 bit and that was a long time ago, when Microsofts int was also 16 bit. So they already shifted it up once. (Going from DOS to Win32 I guess.)
  - Gibbon1 7y ago
    The concept of int hasn't aged very well. People think it's fine because it's always 32 bits on their machine. Go recompile on a machine where it's 16 bits and see how that works out.
- earenndil 7y ago
  What I wonder is, why didn't they add new *printf functions? So you could say 'printf("int64: %d64", x)'
  - boomlinde 7y ago
    Backward compatibility. Your example would impose additional constraints on the %d specifier that would likely break existing code. What if you want an int immediately followed by literal ”64”?
    - earenndil 7y ago
      Oops, I typoed. I said 'new *printf functions'; the example was supposed to be 'printf2("int64: %d64", x)'
      - boomlinde 7y ago
        I see! That would make more sense, but I still think the inttypes.h macros are a sufficient solution. Implementers and standards influencing users probably aren't too keen on another formatting language when you can implement it as macros that only take another few characters to use. printf2("int64: %d64", x); for example isn't significantly shorter than printf("int64: %" PRId64, x); Perhaps it's easier to read, but when you have to support both, and you're more likely to run into the latter than the former anyway, I think it just adds cognitive overhead to have to consider which formatting language is being used.

by hazeii 7y ago

Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portability issues between 32 and 64 bit).

VonChair 7y ago

I think it's important to push forward with getting people out of bad habits. In a lot of cases, the only way to do that is to force it. I don't often agree with things Apple does, but their forcing people to use x64 is similar to this I think.

xscott 7y ago

The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argument to be had over size_t vs ssize_t, but that can wait :-)

madmax96 7y ago
Then there’s the perennial problem of missing format specifiers for POSIX types like pid_t. Although you could argue that POSIX should mandate macros to appropriately handle them, the root problem is the same. The default integer types have not aged well...
- xscott 7y ago
  > missing format specifiers for POSIX types like pid_t This bothers me less because I can always cast it up: fprintf(logfile, "pid: %lld", (long long)pid); Technically not portable, but find a platform with PIDs where this breaks. You can count on long long being at least 64 bits, and I think it'll be a while before we need 128 bit process IDs. :-) > The default integer types have not aged well... To me, the real pisser is that every compiler copped out and decided to leave int at 32 bits when the architecture advanced to 64 bits. Part of the reason for compilers exploiting "signed can't overflow" is so they can work around for loops with 32 bit int variables, and this has ugly consequences because most of the conversion rules in C are defined with respect to int. And honestly, Microsoft should burn for leaving long at 32 bits.
  - jacobush 7y ago
    On Amiga, long was 32 bit and int 16 bit and that was a long time ago, when Microsofts int was also 16 bit. So they already shifted it up once. (Going from DOS to Win32 I guess.)
- Gibbon1 7y ago
  The concept of int hasn't aged very well. People think it's fine because it's always 32 bits on their machine. Go recompile on a machine where it's 16 bits and see how that works out.
earenndil 7y ago
What I wonder is, why didn't they add new *printf functions? So you could say 'printf("int64: %d64", x)'
- boomlinde 7y ago
  Backward compatibility. Your example would impose additional constraints on the %d specifier that would likely break existing code. What if you want an int immediately followed by literal ”64”?
  - earenndil 7y ago
    Oops, I typoed. I said 'new *printf functions'; the example was supposed to be 'printf2("int64: %d64", x)'
    - boomlinde 7y ago
      I see! That would make more sense, but I still think the inttypes.h macros are a sufficient solution. Implementers and standards influencing users probably aren't too keen on another formatting language when you can implement it as macros that only take another few characters to use. printf2("int64: %d64", x); for example isn't significantly shorter than printf("int64: %" PRId64, x); Perhaps it's easier to read, but when you have to support both, and you're more likely to run into the latter than the former anyway, I think it just adds cognitive overhead to have to consider which formatting language is being used.