Fedora Linux Cleared To Pursue Its Modern C Porting

[ryao]

Well, in C it's actually not the same, that's why they want to get rid of it. A function declaration "int foo();" means a function that takes an undetermined number of arguments of undetermined type. Then it's up to the programmer to make sure that when calling the function they use the correct number and type of arguments that match the actual definition of the function foo.

(In C++ an empty argument list is the same as void, this being one of the differences between C and C++.)

I learned C++ shortly after learning C, and did not realize that they differed in this. Meaning an undermined number of arguments reminds me of main() and ioctl(), where the user specifies how many they want to use. It also matches how people write when talking about functions. However, there is no need to put that meaning into a function prototype declaration. That seems silly, but I can see how it would have made sense in the early days if variadic arguments were not part of the language.

They could have just redefined it to match C++. Then newer compilers enforcing the standard would have required people to fix the prototypes anyway, which is the same as what we have now, except people must write void as the argument list.

[F.Ultra]

My hope is that anyone doing this work will try to remove subsequently-deprecated constructs (though, now that I'm looking... I don't know if C11 or C17 actually contain any further deprecations). However, I think it makes sense to set the bar low, because I think they're already undertaking potentially a tremendous amount of work.

C11 deprecated the gets() function.

[gregzeng]

"The Linux Foundation" is slowly and officially moving to the Rust computer language, instead of them many versions of the C computer language. This official press release from Fedora (and Red Hat) seems to be saying the same thing: Rust language might be there next step, after the error-creating C languages.
It's this what any informed journalist should be stating?

[coder]

Today there is much less variability, OS-wise it's mostly a Windows and POSIX/Linux duopoly, and hardware-wise x86 and ARM (with RISC-V making some inroads) dominates.

Not only that, but all the main Linux-supported HW architectures are little-endian or bi-endian, with almost nobody using them in big-endian mode.

I actually wonder if we might see more diversity in mainstream processor ISA and operating systems, in the future. This era could be more of a nexus point, than a terminal convergence.

Today, if you intend to bring a new HW architecture or a new OS to market, you most likely won't develop a compiler from scratch, but instead you contribute support for your HW and/or OS to LLVM (and GCC).

It's true. Even GPUs and AI processors have GCC and LLVM-based backends.

[coder]

GCC support is incomplete (no borrow checker atm, afaik) and is only based on a specific rustc version.
Work is in progress, I expect some things will need to be sorted out as a result of this.

Can the Rust code in the kernel be compiled with it? Or does that require the LLVM-based Rust compiler?

[coder]

C11 deprecated the gets() function.

No, C11 removed gets(). It was actually deprecated in C99.

[bug77]

Can the Rust code in the kernel be compiled with it? Or does that require the LLVM-based Rust compiler?

I have no idea. I would guess no. Keyword: guess.

[microcode]

The features they want to outlaw are, even by C standards, footguns, and the hope is that by generating errors instead of accepting such code it will lead to less buggy code (potentially including bugs that can be exploited).

Implicit int functions and oldstyle functions are not footguns though. What are the footguns?

[coder]

Implicit int functions and oldstyle functions are not footguns though.

From their proposal:

Implicit ints: "Support for this obsolete construct is incompatible with adoption of type inference for auto definitions (which are part of C++ and planned for C as well.).

and:

Old-style functions: "This legacy feature is very close to being incompatible with the C2X standard, which introduces unnamed function arguments."

What are the footguns?

Implicit function declarations are dangerous, because the feature lets you call a function improperly, should you forget to include its header file. If it takes parameters or returns something other than int, your code will be wrong, but it will compile without an error. Compilers can warn you about this, if you turn up the warning level, but the code will still compile and compiling incorrect code is never a good thing.

Omitting void from the argument list is one, since others have noted that it implies a variadic function when you might not have intend it. That allows improper use, without the benefit of a compiler error.