Item — HN Reader

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

1 comments

That defer proposal was the stupidest thing I read in the a long time. Very glad it was rejected.

Well there is a new one: 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.

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.

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.

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.

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...

Pfew it wasn't just me then :-)