4 ms·

It's great of programmers to aim for portability, but frankly it's kind of a stretch that an arbitrary C compiler that is limited in standard support would the

by fuhsnn 1y ago

It's great of programmers to aim for portability, but frankly it's kind of a stretch that an arbitrary C compiler that is limited in standard support would the same time be sophisticated enough to process these tricks as intended. In my fork of chibicc (a small C11 compiler) there are plenty of additional logic that were implemented solely to play nice with C tricks from real world projects that could have been easier if they target later standards. The most recent being how curl's build script determines the size of primitive types: they use (sizeof(T) == N) as a case index and expect the compiler to error on case-duplication[1], I had to add a backtracking loop to check exactly that[2]. I'm not complaining as more error checks isn't a bad thing, however, I'll advise programmers willing to invest in obscure tricks to actually test them on obscure compilers (instead of just flipping -std). [1]: https://github.com/curl/curl/blob/339464432555b9bd71a5e4a4c4e55337cb07118d/m4/curl-functions.m4#L4343 https://github.com/curl/curl/blob/339464432555b9bd71a5e4a4c4... [2]: https://github.com/fuhsnn/slimcc/blob/54563ecae8480f836a0bb262bf56b7beea7b31cf/parse.c#L2380 https://github.com/fuhsnn/slimcc/blob/54563ecae8480f836a0bb2...

listeria 1y ago
If the goal of testing on obscure compilers is to enhance such compilers then I'm all for it. But I don't see much value in having to dance around implementation details to support a compiler which isn't standards compliant. Ideally standards conforming code should just work, that's the point of conforming to a standard.
- immibis 1y ago
  Depends if you want people to be able to use your library with those compilers or not. If it's free software, fine. Don't fire well-paying customers though.
anyfoo 1y ago
curl is one of those projects that's probably meant to be ultra-portable, though, working across an incredibly wide range of platforms, some probably with comparably ancient compilers. I don't actually know any details so I don't want to presume, but it wouldn't surprise me at all if targeting later standards simply isn't an option for the curl project due to portability. It may be that the (sizeof(t) == n) trick may just be what consistently works across all targets. (Until yours came along.) I do remember when configure etc. still had to check whether ANSI prototypes (as opposed to the original K&R style declarations) were supported... I hope that check isn't much of a thing anymore.

by fuhsnn 1y ago

listeria 1y ago

If the goal of testing on obscure compilers is to enhance such compilers then I'm all for it. But I don't see much value in having to dance around implementation details to support a compiler which isn't standards compliant. Ideally standards conforming code should just work, that's the point of conforming to a standard.

immibis 1y ago
Depends if you want people to be able to use your library with those compilers or not. If it's free software, fine. Don't fire well-paying customers though.

anyfoo 1y ago

curl is one of those projects that's probably meant to be ultra-portable, though, working across an incredibly wide range of platforms, some probably with comparably ancient compilers. I don't actually know any details so I don't want to presume, but it wouldn't surprise me at all if targeting later standards simply isn't an option for the curl project due to portability. It may be that the (sizeof(t) == n) trick may just be what consistently works across all targets. (Until yours came along.) I do remember when configure etc. still had to check whether ANSI prototypes (as opposed to the original K&R style declarations) were supported... I hope that check isn't much of a thing anymore.