4 ms·
> It's more like "disregard them at your own risk" I'd argue that a compiler update that breaks existing code for something as innocuous as using the "wrong" v
by coldpie 4y ago
> It's more like "disregard them at your own risk"
I'd argue that a compiler update that breaks existing code for something as innocuous as using the "wrong" variable name is a compiler bug, even if the code technically violates the spec. It is simply too late now for the spec to begin using the keywords they reserved 40 years ago.
- Denvercoder9 4y agoFollowing that reasoning, the C standard library would _never_ be able to add another function (or macro, or struct, or...).
- coldpie 4y agoWithin reason, yeah. Like if they chose to add a new "island" function and my geographics software broke, that's clearly the spec's fault, not mine, even though technically I'm violating spec. I'd even argue any "is.*" function is probably too late to add to the spec at this point in time.
- torstenvl 4y ago> I'd even argue any "is.*" function is probably too late to add to the spec at this point in time. I'd like to see isualpha() isudigit() isupunct() isuspace() isugraph() etc. plus isucombining(). They'd supplement iswxxx() but (a) taking a `signed unicode int` (for C2x defined as at least 32 bits wide) and (b) being locale-independent.
- asveikau 4y agoIn truth they've been careful about introducing names and not breaking existing code. For example, when they finally did a bool type, they called it _Bool to prevent incompatibilities with nonstandard bool types. You needed to include <stdbool.h> to get a friendly, usable name of "bool". There was a similar thing for _Complex.