24 ms·
Modern C for Fedora (and the World)
- wyldfire 3y ago> 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.
- hulitu 3y ago> Part of the problem, perhaps, is that it appears to have fallen on Fedora and GCC developers to make these fixes. Well, they were playing with fire, and now are complaining.
- choeger 3y agoHuh? 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.
- BlackFingolfin 3y agoWell... "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.
- marcthe12 3y agoWell 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.
- dataflow 3y agoWhy not just change the defaults and then add some bypass flags to the compiler to allow old code to compile without hard errors?
- ungamedplayer 3y agoRead the article comments for some of the pedantry on why C compiling has be painful forever. There is no keeping people happy.
- dataflow 3y agoI 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.
- kazinator 3y ago"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
- kazinator 3y ago> first edition of The C Programming Language that many of us still have on our bookshelves I suspect that plenty of people with the second edition on their bookshelves have retired already.
- pjmlp 3y agoStill at least 10 years to go.
- IWeldMelons 3y agoFutile exercise. Compilers should follow the standard, even if it is ugly or dated.
- pjmlp 3y agoThe current standard is C23.
- IWeldMelons 3y agoHave you actually read the article? They want to make the default behaviour to deviate from _all_ known standards.
- pjmlp 3y agoI have, are you sure you're up to date what standards actually say?
- JonChesterfield 3y agoThey 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.
- IWeldMelons 3y agoHave you actually read the article? They want to make the default behaviour to deviate from _all_ known standards.
- uecker 3y agoI 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.
- ho_schi 3y agoThe C Programming Language 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.
- anthk 3y agoI have one in HTML.
- fractalb 3y agoIs 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.
- asicsp 3y agohttps://lwn.net/ml/fedora-devel/87jzpztbfg.fsf@oldenburg.str.redhat.com/ https://lwn.net/ml/fedora-devel/87jzpztbfg.fsf@oldenburg.str... might help
- fractalb 3y agoThanks. The link seems to list relevant links and repos. I'll see how I can help now.
- rwmj 3y agohttps://src.fedoraproject.org/rpms/nbdkit https://src.fedoraproject.org/rpms/nbdkit (replace "nbdkit" with the package name)
- fractalb 3y agoThanks. This helps even more. I need not go through all the packages. I'll get a fedora account now :)
- cremno 3y agoBesides 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.
- tjoff 3y ago> 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.
- spacechild1 3y agoOr when the type is hidden (lambdas). Or to avoid needless redundandancy (e.g : auto foo = std::make_unique<Foo>()). And probably some more.
- kazinator 3y agoC 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.
- pjmlp 3y agoIt is already there in C23.
- kazinator 3y agoThere 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.
- quelsolaar 3y agoA 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.
- EPWN3D 3y agoIntroduce 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.
- kazinator 3y agoOne K&RC construct can sneak into new C by accident. A lost C++ developer might wander into a C program and write: void fun() { } which is fully declared in C++, but in C it is an old-style function definition that doesn't declare anything about its arguments.
- pjmlp 3y agoIn C23 has the same semantics as in C++.
- el_pollo_diablo 3y agoNot 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.
- kazinator 3y agoI have N3096.pdf (April Fool's 2023 draft) perpetually open; will check it.
- simiones 3y agoI 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`) ?
- quelsolaar 3y agoYou are right. void pointers can convert to any pointer type in C. That's why you don't need to cast malloc in C.
- cmovq 3y agoGCC 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;’
- EPWN3D 3y agoI really prefer sizeof(*c) in that expression to protect against a badly-sized allocation of c's type changes.
- qalmakka 3y ago> Inconsistent return statements Returning the wrong data type has been an error with Clang since the earliest days. Why does GCC still allow that?
- deleted 3y ago[deleted]
- nolist_policy 3y agoIt doesn't: 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; | ^
- brabel 3y agoHorrifying 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.
- munch117 3y agoThe term is weakly typed. Weak vs. strong and dynamic vs. static are orthogonal.
- 3836293648 3y agoC was mostly a statically weakly typed language. I can't think of anything else in that space
- uecker 3y agoThe 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: https://bugs.gentoo.org/show_bug.cgi?id=gcc-14 https://bugs.gentoo.org/show_bug.cgi?id=gcc-14
- e12e 3y agoInteresting - normally lwn links posted here are shared with access (a promo link) - this one appears to be behind a paywall?
- adamrezich 3y agoweird—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/Articles/954018/ https://web.archive.org/web/20231222032328/https://lwn.net/A...
- deleted 3y ago[deleted]