> C++ has already adopted type inference, where the compiler figures out what the appropriate type for the variable should be from how it is used, in this case. There are schemes afoot to add a similar feature to C, but type inference is incompatible with implicit int.
Please no. In C++ this only makes sense when you have huge templated types such as iterators etc. Or inside templates where the types are not fixed.
Neither exist in C. It is just a distraction with no benefits in C.
C has type generic math (which came first) and something called generic selection via _Generic (which came later, and provides a model for implementing the type generic math stuff).
I suspect that a C++-like auto could be of benefit in conjunction with that stuff.
Yes 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:
I 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.
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.
I 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.
If 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.
I 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.
I'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.
You 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.
Maybe 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.
You 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.
Compilers 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
The 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.
That 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.
There is some discussion there about whether it's a good idea to enable -Werror: make all warnings errors (which breaks builds for users that use a newer compiler that introduces new warnings) Someone said, how about doing that for version control checkouts. But downstream users use version control checkouts too.
I have a solution for that kind of thing: ./configure --maintainer.
If the building user identifies as a maintainer, then some things can happen differently. Stricter compiler options may be one. Another thing you might do in maintainer mode is update generated files (e.g. Yacc parsers) rather than using the canned, shipped code.
In TXR's ./configure, maintainer mode enables parallel make, which is suppressed otherwise. There is a way to enable it without requesting maintainer mode. Parallel make asks for problems because it can introduce race conditions into build steps, causing builds to intermittently fail. So in keeping with the theme of not breaking users, we disable it --- unless they announce themselves to be developing users via maintainer mode.
A few things to note and out this. Yes feel free to enable -Werror, but warnings are implementation specific, so there is no way to write portable C code that is warning free. A compiler can issue a warning for anything, like you using a computer, or you should mind you knees when walking stairs.
There is a worrying trend about -Werror, and that is that people turn it on and then when compilers add new warnings, builds fail and developers complain to the compiler developers. This is BAD. we should encourage compiler developers to find as many warnings as possible, and then users should turn off the once they don't like. Juste because a warning is stupid to you doesn't mean that it wont catch a bug for someone else. Compiler developers are responsible for correctly compiling your code, not to keep your code warning free.
I have spoken to several compiler developer who don't want to add new valid warnings because of the vitriol they will receive from developers.
Introduce an error epoch and let maintainers advance it at whatever pace they'd like. You could even select a more recent epoch for your local builds and keep your CI builds on an earlier epoch until you've qualified against the most recent one.
> The page you have tried to view (Modern C for Fedora (and the world)) is currently available to LWN subscribers only. Reader subscriptions are a necessary way to fund the continued existence of LWN and the quality of its content.
Not sure if this somehow changed at LWN because I thought I'd been able to look at this article before.
int main(void) {
struct {
int a;
} s;
return;
return &s;
return s;
}
$ gcc test.c
test.c: In function ‘main’:
test.c:5:3: warning: ‘return’ with no value, in function returning non-void
5 | return;
| ^~~~~~
test.c:1:5: note: declared here
1 | int main(void) {
| ^~~~
test.c:6:10: warning: returning ‘struct <anonymous> *’ from a function with return type ‘int’ makes integer from pointer without a cast [-Wint-conversion]
6 | return &s;
| ^~
test.c:7:10: error: incompatible types when returning type ‘struct <anonymous>’ but ‘int’ was expected
7 | return s;
| ^
Is there some place where I can see all the packages that need to be fixed and raise a pull request for any package? Maybe, I can help with some fixes during the holiday season.
Besides fixing bad C code: how many of those packages are still properly maintained? The Ruby ones don't seem to be. Fedora and other distros likely have to build their packages with patches.
I did read the article. Unless I missed something, I didn't see anything about why they couldn't add some mechanism to bypass these warnings for old files.
"They" (e.g. GCC maintainers) do. You have dialect options like -std=c90, and fine-grained control over diagnostics: you can disable or enable individual warnings, or have them treated as errors.
GCC compiles C with a certain default dialect. It used to be gnu89 for the longest time, then gnu99 for a while. Now it is gnu11, if not higher. This default dialect is not ISO C; it's a GNU dialect.
So just to have your code processed as ISO C, you have to use a non-default option. Some GNU extensions are still recognized (rather than diagnosed as syntax errors) so if you wish not to accidentally use those, you need -pedantic also.
In Makefiles, you can tweak compiler options for individual files. E.g. with target-specific assignments in GNU Make.
# don't warn about conversions in old_parser.c
old_parser.o: CFLAGS += -Wno-conversion
The standard version is a TU-wide flag which doesn't help with headers. And it seems like the proposal here is to change the standard so that those legacy constructs are outright rejected. So my question was, if you're going to change the default in the standard, why not provide a per-header escape hatch for old code?
I'm not sure which meaning/nuance of standard you are referring to, but the ISO C standard doesn't specify any flags mechanism, translation-unit-wide or otherwise.
The GCC implementation (and likely Clang also) supports altering diagnostics over sections of a translation unit.
I wonder if this item, "Assignments between incompatible pointer types" includes what I understood is (was?) actually recommended practice in C - `int *c = malloc(sizeof(int))`. Has the preferred style changed, or is this only a problem for non-void pointer types (i.e. `float *p = &some_int`) ?
GCC will not warn with implicit void pointer conversions, I believe that’s explicitly allowed. It’s only when you have incompatible types like ‘float *y = (int *)x;’
Not exactly. As of C17, the function definition you wrote implies that the function has no arguments, just like in C++. However, a declaration that is not part of a definition, like
void fun();
(which you typically find in a header file) indeed does not say anything about the function's arguments. You have to write
void fun(void);
to specify that the function takes no arguments. For consistency, you can (and probably should) also use that style in the function's definition, but you don't have to.
Anyway, C23 will align C's behavior with C++: void fun() will mean the same thing as void fun(void), whether as part of a function definition or not.
Does someone now a source of the 2nd Edition “ANSI C” with a good print quality? The ones sold by Amazon seem to be scans and no based on digital typesetting - which is mentioned in the first pages.
weird—it wasn't that way initially when I loaded the page earlier today, but refreshing the tab shows that it is indeed paywalled now. the earlier, unpaywalled version is available on archive.org: https://web.archive.org/web/20231222032328/https://lwn.net/A...
Huh? Who's been playing with fire? Fedora ships 15k packages. They don't develop them. They're trying to modernize hundreds of packages on a volunteer basis.
Well... "it appears to have fallen on Fedora and GCC developers" suggests they are are forced into doing this. But it's the reverse: they decided this is a sensible goal. OK, they are free to do that, but painting it as if they are unfairly left alone in their plight is framing it rather strongly.
Well Clang also did this for clang 16 and tried to ship it with 16. Most of these were K&R C constructs that were deprecated in c89. c23 kinda removes and in one case even repurposes the code. So on GCC and Clang side, it was c23 compliance and on fedora and gentoo(which also helped) force by compiler defaults.
They do. That's what the whole -std=c99 flag asks for. You either tell the compiler what language the text files are supposed to contain or it takes a guess.
I haven't read the article, but following this effort from the compiler side, I do not think this is the case. Also there is exactly one ISO C standard. Newer versions supersede older ones from a legal point of view. The current one is ISO C17 which will soon be replaced by ISO C23 (officially next year). Older C standards are historical documents and code targeting them is not conforming to ISO C. The C committee takes extreme care not to break existing code except for very good reasons. So code that can only be compiled assuming older versions of ISO C will likely use questionable constructs which were removed in later versions for good reasons.
Horrifying how old C was basically a dynamically typed language, but without type checks even at runtime.
I would love to help modernize these tools. Is the process to submit a merge request still based on mail lists? Can I just open a GitHub Pull Request somewhere if I decide to fix some package? Is there a list of packages that no one has picked up yet?
I'm sure you could get lots of people like me willing to help if you just made contributions a bit easier to make.
The process depends on the package. If there is an active upstream project, a github pull request or similar would often do. It might be a good idea to coordinate with the distributions involved. For gentoo, a tracking bug seems to be here:
Please no. In C++ this only makes sense when you have huge templated types such as iterators etc. Or inside templates where the types are not fixed.
Neither exist in C. It is just a distraction with no benefits in C.