On 1/19/24 7:38 AM, Alan Somers wrote:
On Fri, Jan 19, 2024 at 6:56 AM Alan Somers <[email protected]> wrote:
On Thu, Jan 18, 2024 at 10:32 PM Enji Cooper <[email protected]> wrote:
On Jan 17, 2024, at 2:50 PM, Alan Somers <[email protected]> wrote:
The branch main has been updated by asomers:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8bae22bbbe6571da9259e0d43ffa8a56f4b3e171
commit 8bae22bbbe6571da9259e0d43ffa8a56f4b3e171
Author: Alan Somers <[email protected]>
AuthorDate: 2024-01-15 23:49:47 +0000
Commit: Alan Somers <[email protected]>
CommitDate: 2024-01-17 22:49:41 +0000
fusefs: prefer new/delete over malloc/free
MFC after: 2 weeks
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43464
Why not use smart pointers instead?
-Enji
Only because this stuff all evolved from C code. Smart pointers would
certainly work.
Actually, TBH it's because I'm not real great with C++. It's a
difficult language, and after 2016 I stopped even trying to improve my
C++ skills. Instead, I've been focusing on Rust. Even when I wrote
these tests in 2019, I strongly considered using Rust instead of C++.
In the end, the only thing that forced me to use C++ is because I
wanted them to live in the base system, rather than in ports.
I still dream about the day when Rust is allowed in the base system.
If it were, then in addition to these tests, I would've converted
gstat to Rust (rather than add sysutils/gstat-rs to ports), added the
nfs-exporter (instead of putting it in net-mgmt/nfs-exporter), added a
ctl-exporter (which is impossible to do in ports, so I had to do that
one in C), and converted tools/regression/fsx in place (instead of
putting in devel/fsx-rs). Maybe a couple of other things, too. Like
ztop, or the geom-exporter that I have half-written. I've also been
tempted to rewrite zfsd in Rust.
Alas, I sense that there is little appetite for bringing Rust into contrib.
Brooks' opinion is that to support Rust in base we probably need to require
always using an external toolchain as otherwise we would need to keep two
copies of LLVM in base.
--
John Baldwin
