[TUHS] yet another C discussion (YACD) and: Rust is not C++

Alejandro Colomar alx.manpages at gmail.com
Tue Jan 31 11:47:18 AEST 2023


Hello Ron,

On 1/30/23 20:35, ron minnich wrote:
> I don't know how many ways there are to say this, but Rust and C/C++ are 
> fundamentally different at the lowest level.
> 
> If you are just looking at Rust syntax in a superficial way, you might be 
> excused for thinking it's "C with features / C++ with differences."
> 
> But that's not how it is. It's like saying C is "just like assembly" because 
> labels have a ':' in them; or that Unix is "just like RSX" because they have 
> vaguely similar commands.
> 
> Here's a real question that came up where I work: should the code shown below be 
> accepted (this is abstracted from a real example that is in use ... everywhere)?
> We had one code analyzer that said, emphatically, NO; one person said YES, 
> another MAYBE. One piece of code, 3 answers :-)
> 
> char f() {
> 
> char *y;
> 
> g(&y);
> 
> return *y;
> 
> }
> 
> 
> A specific question: should y be initialized to NULL?

No.  At least not if you don't want to use the value NULL in your program. 
Using NULL as something to avoid Undefined Behavior is wrong, and it will 
contribute to hide programmer errors.

These days, compilers and static analyzers are smart enough to detect 
uninitialized variables, even across Translation Units, and throw an error, 
letting the programmer fix such bugs, when they occur.

The practice of initializing always to NULL and 0 provides no value, and 
silences all of those warnings, thus creating silent bugs, that will bite some 
cold winter night.

I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't 
initialize variables and especially pointers (well, you need to enable the 
warning that does that, but it can warn).  That warning is there due to some 
coding style or certifications that require it.  I recommend disabling those 
bogus warnings, and forgetting about the bogus coding style or certification 
that requires you to write bogus code.

> The case to set y to NULL: otherwise it has an unknown value and it's unsafe.

Is an undefined value less safe than an unexpected one?  I don't think so.  At 
least compilers can detect the former, but not the latter.

> The case against setting y to NULL: it is pointless, as it slows the code down 
> slightly and g is going to change it anyway.

Performance is a very minor thing.  But it's a nice side-effect that doing the 
right thing has performance advantages.  Readability is a good reason (and in 
fact, the compiler suffers that readability too, which is the cause of the 
silencing of the wanted warnings.

> The case maybe: Why do you trust g() to always set it? Why don't you trust g()? 
> convince me.

Well, it depends on the contract of g().  If the contract is that it may not 
initialize the variable, then sure, initialize it yourself, or even better, 
check for g()'s errors, and react when it fails and doesn't initialize it.

If the contract is that it should always initialize it, then trust it blindly. 
The compiler will tell you when it doesn't happen (that is, when g() has a bug).

> 
> You can't write this in Rust with this ambiguity. It won't compile. In fact, & 
> doesn't mean in Rust what it does in C.

I don't know Rust.  Does it force NULL initialization?  If so, I guess it's a 
bad design choice.  Unless Rust is so different that it can detect such 
programmer errors even having defined default initialization, but I can't 
imagine how that is.

> 
> Sorry to be such a pedant, but I was concerned that we not fall into the "Rust 
> is C++ all over again" trap.
> 
> As for replacing C, the velocity of Rust is just astonishing. I think folks have 
> been waiting for something to replace C for a long time, and Rust, with all its 
> headaches and issues, is likely to be that thing.

Modern C is receiving a lot of improvements from C++ and other languages.  It's 
getting really good in fixing the small issues it had in the past (and GNU C 
provides even more good things).  GNU C2x is quite safe and readable, compared 
to say ISO C99 versions.

I don't think C will ever be replaced.  And I hope it doesn't.

Possibly, something like with Plan9 and Unix/Linux will happen.  The good things 
from other languages will come back in one form or another to C.  The 
not-so-good ones will be discarded.

> 
> Personally, I still prefer Go, but I can also see which way the wind is blowing, 
> especially when I see Rust use exploding in firmware and user mode, and now even 
> in the Linux kernel.

Cheers,

Alex


More information about the TUHS mailing list