4 ms·

I'll start caring about c standards above gnu99 as soon as they add case range values to switch statements, like case A ... B: -- which I've only been using for

I'll start caring about c standards above gnu99 as soon as they add case range values to switch statements, like case A ... B: -- which I've only been using for what, 35 years now? All that time, I really wondered what the flip they are on about. Adding extensions that really, I really raise eyebrows at while ignoring complete elephants in the room, like the above feature. Last year they were pontificating about something something adding some sort of (complicated) syntax to support destructor functions and were wondering about prior implementations, and I had to point to them the support of destructor function had been there as an extension of gcc for countless years. It's like they aren't actually using the language, just speccing it. Kinda like linux maintainers who are more like some sort of priesthood and gatekeepers than actual users of the system.

saagarjha 3y ago
The language authors can be shortsighted, but they're not stupid. The discussion of destructors has proceeded for years and everyone there knows that GCC already has __attribute__((cleanup)).
uecker 3y ago
Everybody in WG14 is fully aware of the GNU extensions. Also many of us are active C users (but maybe not enough). With complicated syntax you mean the "defer" proposal?. In any case, different people have different priorities and ideas. The best way to influence decisions is to contribute to the standardization process. For example, everybody can submit proposals. But regarding case range values, there is now one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm
- rwmj 3y ago
  That defer proposal was the stupidest thing I read in the a long time. Very glad it was rejected.
  - uecker 3y ago
    Well there is a new one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm But calling things "stupid" is relatively useless internet noise and the best way to be ignored.
    - rwmj 3y ago
      It's funny that they summarise all the ways that attribute((cleanup)) is already being used successfully, then make up some stuff about a problem that it allegedly has (which doesn't affect any of the users), then try to shoehorn defer in again. Just standardize attribute((cleanup)) as it is already widely implemented and used, and stop messing around with defer nonsense.
      - uecker 3y ago
        Not my proposal, but what exactly do you dislike about it? cleanup is unlikely to be standardized exactly as implemented as it would violate the rule that standard attributes can be removed from a correct program.
        rwmj 3y ago
        That it would require rewriting everything that is already using attribute((cleanup)), which is a lot of code these days. Just make-work for no benefit. > it would violate the rule Good, let's change that rule for this case.
        uecker 3y ago
        While I agree that there is some value in putting an existing extension into the standard as is, not doing so would not mean that everybody has to rewrite their code. Code that already uses a non-standard attribute could simply continue to do so. I would just not automatically become standard compliant. I think changing the rule would create a mess, so I am not in favor of this. I wonder if there is a way so that existing macro wrappers could be adapted...

saagarjha 3y ago

The language authors can be shortsighted, but they're not stupid. The discussion of destructors has proceeded for years and everyone there knows that GCC already has __attribute__((cleanup)).

uecker 3y ago

Everybody in WG14 is fully aware of the GNU extensions. Also many of us are active C users (but maybe not enough). With complicated syntax you mean the "defer" proposal?. In any case, different people have different priorities and ideas. The best way to influence decisions is to contribute to the standardization process. For example, everybody can submit proposals. But regarding case range values, there is now one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm

rwmj 3y ago
That defer proposal was the stupidest thing I read in the a long time. Very glad it was rejected.
- uecker 3y ago
  Well there is a new one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm But calling things "stupid" is relatively useless internet noise and the best way to be ignored.
  - rwmj 3y ago
    It's funny that they summarise all the ways that attribute((cleanup)) is already being used successfully, then make up some stuff about a problem that it allegedly has (which doesn't affect any of the users), then try to shoehorn defer in again. Just standardize attribute((cleanup)) as it is already widely implemented and used, and stop messing around with defer nonsense.
    - uecker 3y ago
      Not my proposal, but what exactly do you dislike about it? cleanup is unlikely to be standardized exactly as implemented as it would violate the rule that standard attributes can be removed from a correct program.
      - rwmj 3y ago
        That it would require rewriting everything that is already using attribute((cleanup)), which is a lot of code these days. Just make-work for no benefit. > it would violate the rule Good, let's change that rule for this case.
        uecker 3y ago
        While I agree that there is some value in putting an existing extension into the standard as is, not doing so would not mean that everybody has to rewrite their code. Code that already uses a non-standard attribute could simply continue to do so. I would just not automatically become standard compliant. I think changing the rule would create a mess, so I am not in favor of this. I wonder if there is a way so that existing macro wrappers could be adapted...