5 ms·
And its broken! Consider: auto i = 0.0; i is a double in C23 but an int in earlier version. Please don't use C23.
by quelsolaar 3y ago
And its broken! Consider:
auto i = 0.0;
i is a double in C23 but an int in earlier version. Please don't use C23.
- lionkor 3y ago0.0 is a double literal, how is that broken?
- quelsolaar 3y agoBecause it changes the meaning of existing code. That's a big no-no.
- JonChesterfield 3y agoMaybe people could grep for "auto" in their codebase, see it's not there, and then change to C23? Though realistically if this looks like a problem it's a trivial compiler diagnostic. "Would this thing have a different type in C23 to earlier? Emit a warning, promotable to error". The whole changes meaning panic is rather overdone and mostly acts to stop C improving over time.
- actionfromafar 3y agoChesters' (green) field, where Chesterton's fence is. :)
- quelsolaar 3y agoYou cant make a compiler diagnostic, because it was valid before and after C23, the code just means different things. In fact just using auto without a type was bad practice in earlier versions, now it can be considered a feature, so its less likely to give you a warning now than in the past.
- JonChesterfield 3y agoThe obvious diagnostic would be "if auto and < C23, emit warning". That can definitely be implemented. Choosing the name would take longer than writing the code. Lots of stuff is valid and gets warnings on request, like `if (a = b)`, or anything where people get precedence or aliasing rules often enough that someone bothered to patch the compiler.
- quelsolaar 3y agoThat is if you know about this issue. Very few people do. At some point C23 may become a default version of C in some compilers and someone who has been building code without specifying what version of C they use, will silently get a bug. That is the problem. There is no way for a C compiler to look at the code and determine what version it was written for.
- uecker 3y agoImplicit int was removed in C99. Since then most compilers warn about this in default compilation mode.
- jcelerier 3y agoCompilers already have diagnostic for these exact things ("because it was valid before and after C23, the code just means different things"), e.g. all the -wc99-compat warnings
- kinjamee 3y agoSeems like a simple fix, just do a global search & replace of 'auto' with 'int'. In the rare case where someone used 'auto type foo' you'll get compiler errors and can easily fix those. I have never actually seen auto used in a C code base.
- quelsolaar 3y agoYes the use of auto is rare, and should not be used in the first place. Still i don't like silently breaking old code. You cant just do a search and replace. This is valid: auto float f; so a search and replace would break that code.
- munch117 3y agoSearch-replace has its problems: auto tautology = sizeof("automatons are on auto"); but int float f; is not a big one: The compiler will flag it as a syntax error, and you fix it as it comes.
- quelsolaar 3y agoI agree. The big problem here is that the meaning of a rare but valid peace of code has changed and almost no one knows about it. We don't break user space.
- munch117 3y ago> We don't break user space. That's one strategy. It has consequences, such as keeping around K&R declarations and implicit pointer/int conversion for decades after they started being warned against. Other strategies may have merit.
- Brian_K_White 3y agoI don't think either of those examples is the same. The problem isn't merely gaining or losing features or syntax, it's changing the meaing and behavior of an existing thing. Code is the definitive source of truth for the thing someone devised. It's not just a thing, it's the reference for how to implement the thing. If you have a recipe from 100 years ago that refers to ingredients and tools that are no longer available, or are now called something else, or need to be translated into current equivalents, those are all no problem. But if the old recipe uses a term that we do still have, but means something different now than it did when written, that's a problem. Now you're breaking the very concept of writing and communicating and documenting. That's not a sane thing to do intentionally. Think scientific and industrial processes not just cakes. In this particular case, since the feature happens to be presumed to be rarely used, it might be fairly easily addressed by just having the compiler issue a full stopping error for any use of auto by default, including the reason why so that the user doesn't just blindly add the flag to allow it. In the future, when someone tries to build some code, it will fail to build, and that is 1000% prefferable to successfully building the wrong output.
- bluetomcat 3y agoI'm doing a lot of C in the last 15 years, and have never seen usage of "auto" in any codebase. It's an ancient way to declare a local variable from the early "typeless" days of C.
- quelsolaar 3y agoYou are right it is bad to use typeless variables, and its also bad to use auto in C23 to infer type. So this code should never be written, but its still bad to break existing code.
- gpderetta 3y agoI suspect that nobody outside of C conformance suites or compiler unit tests has used auto in C, at least in the last 30 years.
- munch117 3y agoIf anyone actually ever wrote that, pre-C23, then more likely than not they intended for i to be a double. Otherwise, why write 0.0 when 0 would suffice? It could go either way: Switching to C23 could cause a bug, or it could fix a bug. Or maybe fix one bug and cause another.
- jcelerier 3y agoI actually fixed this exact bug in a C library recently which used auto most likely because the author was used to using it in C++, it compiled and went through. Led to very spicy behaviour in C.