lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240111152414.35517-1-ecurtin@redhat.com>
Date: Thu, 11 Jan 2024 15:24:14 +0000
From: Eric Curtin <ecurtin@...hat.com>
To: airlied@...il.com
Cc: dhowells@...hat.com,
	hpa@...or.com,
	jhubbard@...dia.com,
	linux-kernel@...r.kernel.org,
	pinskia@...il.com
Subject: Re: [PATCH 00/45] C++: Convert the kernel to C++

> You don't just need coding standards, you need a compiler that refuses
> to compile that stuff.
> 
> If you want C++ to do what Rust could do, then you need the compiler
> to stop the stupid before you can even write it, otherwise people will
> still write the bad stuff and code review won't catch it all.

Completely agree with this by the way, if you could turn off features
easily via C++ compiler flags, etc. and make usage of the unwanted
features throw errors. There is a subset of C++ that would have been
useful in the kernel many years ago.

I think the C++ committee is coming around to this way of thinking with
profiles. But it should extend to more than just memory safety features
of course.

Some of the things I like about C++ over Rust:

- C++ interop with C is easier, you can just intertwine C and C++
  together out of the box once your code is compiling with C++.
- It's already on the majority of platforms, even legacy ones.

But Rust is nice for other reasons.

But yeah something like this would need to be done like the Rust integration
effort and be an opt-in thing for new code, if it was done.

> 
> Can we get memory safety with C++ now? and also stop people coding C++
> like it's 1994?
> 
> Kernel C has kinda become a thing without enforcing it, but C wasn't
> really stopping anything bad, so having C that isn't quite kernel C
> get into corners isn't that bad, but introducing C++ without any
> history of kernel C++ is just asking for everyone to do their own
> special things and defend their usage of every corner of the language
> because they wanted to learn it.
> 
> Dave.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ