Re: adding some C++ in the code?

"Dustin J. Mitchell" <[email protected]> Tue, 17 Sep 2019 14:20:13 -0400
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <CAJtE5vRx8ABS8DYdK81RSEiF=eFCobE5rDvvOfuYUWx11n-e9w@mail.gmail.com>
--000000000000351aa50592c3c6e5
Content-Type: text/plain; charset="UTF-8"

I think Amanda predates C++ being at-all portable, so that might be part of
the reasoning behind the lack of C++ in the codebase.  Amanda used to be
supremely portable -- able to run on AIX and FreeBSD and HP/UX and Windows
XP.  I think there are fewer, more standard platforms these days.

Adding a dependency on Glib and using its "class" functionality was a good
improvement, but yes -- brings a great deal of precompiler magic to bear.

Just to suggest a few alternatives to weigh:

 * just leave it -- how often do these things change?

The balance here would be between time saved in having to modify yet
another macro, vs. time lost getting C++ linkage working on all platforms,
modifying the build process, interfacing via SWIG, etc.

 * rewrite more things in Perl

The original idea with the Perl work was to slowly boil away the C code
until it was basically just the xfer support and anything else dealing with
raw data.  As you've seen, even the SCSI interface code is written in
Perl.  Although Perl hasn't turned out to be the popularity juggernaut I
had hoped, it has the advantage over a compiled language that users can
"live-patch" their systems to explore and debug, which encourages further
contributions.  This was originally being done in a top-down fashion,
rewriting the user-facing stuff in Perl and slowly chasing down the
dependency tree, such that C code never relied on Perl code.  That, too
could be reconsidered, and perhaps for example the config parsing could be
rewritten in Perl, with (autogenerated?) bindings to allow accessing it in
C.

 * add Rust instead of C++

Many of the bugs in Amanda are around precisely the things that Rust fixes
-- memory safety, concurrency, etc.  These are *particularly* hard to get
right in C where you don't have infrastructure like smart pointers, and
must rely on comments like "takes ownership of its third argument".  The
transfer architecture, in particular, has a lot of funny business about
buffer ownership that probably hides a few bugs.  Rewriting that in Rust
would probably enable performance improvements while also fixing such
safety issues.

Dustin


On Tue, Sep 17, 2019 at 1:14 PM Chris Hassell <[email protected]>
wrote:

> Hi, there.
>
> There comes a time when I've seen too many #defines and every single one
> of them is just a way to boilerplate either (a) a constructor or (b) a
> destructor or (c) an access point that is shaped by the object type or
> (d) type-dependent reusable versions of a-c.
>
> For the configuration code, I think its time we considered having it,
> but without the full stdc++ library (not too hard).
>
> This just so long as any changes can pass muster with the self-test and
> continue to work.  But the size of the config setup and the insanity in
> getting to some parts or knowing some states of a config makes the
> number of access functions really enormous and very confusing.
>
> There are other areas ... but C++ can have fully-compatible C bindings.
>
> Any objections?   Why all the pitchforks and torches?
>
>      -- CH
>
> Confidentiality Notice | The information transmitted by this email is
> intended only for the person or entity to which it is addressed. This email
> may contain proprietary, business-confidential and/or privileged material.
> If you are not the intended recipient of this message, be aware that any
> use, review, re-transmission, distribution, reproduction or any action
> taken in reliance upon this message is strictly prohibited. If you received
> this in error, please contact the sender and delete the material from all
> computers.
>
>

--000000000000351aa50592c3c6e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think Amanda predates C++ being at-all portable, so=
 that might be part of the reasoning behind the lack of C++ in the codebase=
.=C2=A0 Amanda used to be supremely portable -- able to run on AIX and Free=
BSD and HP/UX and Windows XP.=C2=A0 I think there are fewer, more standard =
platforms these days.</div><div><br></div><div>Adding a dependency on Glib =
and using its &quot;class&quot; functionality was a good improvement, but y=
es -- brings a great deal of precompiler magic to bear.</div><div><br></div=
><div>Just to suggest a few alternatives to weigh:</div><div><br></div><div=
>=C2=A0* just leave it -- how often do these things change?</div><div><br><=
/div><div>The balance here would be between time saved in having to modify =
yet another macro, vs. time lost getting C++ linkage working on all platfor=
ms, modifying the build process, interfacing via SWIG, etc.<br></div><div><=
br></div><div>=C2=A0* rewrite more things in Perl</div><div><br></div><div>=
The original idea with the Perl work was to slowly boil away the C code unt=
il it was basically just the xfer support and anything else dealing with ra=
w data.=C2=A0 As you&#39;ve seen, even the SCSI interface code is written i=
n Perl.=C2=A0 Although Perl hasn&#39;t turned out to be the popularity jugg=
ernaut I had hoped, it has the advantage over a compiled language that user=
s can &quot;live-patch&quot; their systems to explore and debug, which enco=
urages further contributions.=C2=A0 This was originally being done in a top=
-down fashion, rewriting the user-facing stuff in Perl and slowly chasing d=
own the dependency tree, such that C code never relied on Perl code.=C2=A0 =
That, too could be reconsidered, and perhaps for example the config parsing=
 could be rewritten in Perl, with (autogenerated?) bindings to allow access=
ing it in C.<br></div><div><br></div><div>=C2=A0* add Rust instead of C++</=
div><div><br></div><div>Many of the bugs in Amanda are around precisely the=
 things that Rust fixes -- memory safety, concurrency, etc.=C2=A0 These are=
 *particularly* hard to get right in C where you don&#39;t have infrastruct=
ure like smart pointers, and must rely on comments like &quot;takes ownersh=
ip of its third argument&quot;.=C2=A0 The transfer architecture, in particu=
lar, has a lot of funny business about buffer ownership that probably hides=
 a few bugs.=C2=A0 Rewriting that in Rust would probably enable performance=
 improvements while also fixing such safety issues.</div><div><br></div><di=
v>Dustin<br></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Tue, Sep 17, 2019 at 1:14 PM Chris Hassell &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, there.=
<br>
<br>
There comes a time when I&#39;ve seen too many #defines and every single on=
e<br>
of them is just a way to boilerplate either (a) a constructor or (b) a<br>
destructor or (c) an access point that is shaped by the object type or<br>
(d) type-dependent reusable versions of a-c.<br>
<br>
For the configuration code, I think its time we considered having it,<br>
but without the full stdc++ library (not too hard).<br>
<br>
This just so long as any changes can pass muster with the self-test and<br>
continue to work.=C2=A0 But the size of the config setup and the insanity i=
n<br>
getting to some parts or knowing some states of a config makes the<br>
number of access functions really enormous and very confusing.<br>
<br>
There are other areas ... but C++ can have fully-compatible C bindings.<br>
<br>
Any objections?=C2=A0 =C2=A0Why all the pitchforks and torches?<br>
<br>
=C2=A0 =C2=A0 =C2=A0-- CH<br>
<br>
Confidentiality Notice | The information transmitted by this email is inten=
ded only for the person or entity to which it is addressed. This email may =
contain proprietary, business-confidential and/or privileged material. If y=
ou are not the intended recipient of this message, be aware that any use, r=
eview, re-transmission, distribution, reproduction or any action taken in r=
eliance upon this message is strictly prohibited. If you received this in e=
rror, please contact the sender and delete the material from all computers.=
<br>
<br>
</blockquote></div>

--000000000000351aa50592c3c6e5--