[Toybox] [PATCH] md5sum: fix libcrypto build.

Sat Jun 5 04:02:10 PDT 2021

On 6/4/21 10:43 AM, enh wrote:
>     I had some more cleanup I wanted to do anyway, which removes the enum.
> 
> i have to admit i was surprised that you'd left the enum. if i hadn't just had
> my second dose i might have thought a bit harder and waited. probably won't be a
> friday toybox update this week anyway :-)

I totally missed the build break in the other config and needed the poke.

>     P.P.S. Huh, I wonder if I can get gcc to stop "optimizing" out checkes for
>     signed integer overflow if I declare the darn variable volatile? No, I'm pretty
>     sure I would have tried that... 
> 
> i think -fwrapv is the option for "i'd rather have the language they _should_
> have specified rather than the last 0.01% performance". as i've said many times,
> this is nothing to do with C++. it's all about the compiler writers promos being
> based on 0.01% benchmark improvements by exploiting loopholes in the language
> rather than closing the loopholes to make software safer. which is why -- as
> insecurity becomes ever harder to ignore -- we're starting to see some
> meaningful linguistic alternatives.
> 
> to be fair, neither C nor C++ seems likely to be salvageable anyway,

I miss twitter:

  https://twitter.com/landley/status/1037375674212933632

> even if the
> compiler writers and folks on the standards committee were moving in the right
> direction. so maybe they're doing the world a favor by hastening their demise.

C is a portable assembly language. There's a need for something like it and
nothing else is better at being C than C.

Hastening the demise of C++ definitely does the world a favor, yes.

I agree that "how much code really needs to be written in assembly-ish language
vs higher level languages" is an old argument that shifts upwards over time. But
people were predicting the elimination of all use of assembly language back when
the first Cobol and Fortran compilers came out, and yet...

> (i haven't yet _used_ Rust, but i can't help but feel they managed to snatch
> defeat from the jaws of victory with signed integer overflow by having different
> behavior for debug and release builds --- aiui debug builds are the equivalent
> of -ftrapv and release builds the equivalent of -fwrapv. i've also never used
> Swift, but at least on paper that seems to actually be the best of the current
> options, explicitly forcing you to choose by using differently-spelled wrapping
> or trapping operators. Rust does have _all_ the choices: wrap, trap, saturate,
> or something very like C/C++'s __builtin_add_overflow, but [afaik] they're all
> as unergonomic as __builtin_add_overflow. Swift's `+` versus `&+` style --
> though, again, i've never used it -- seems like something that would greatly
> improve a lot of the CVE-prone C/C++ i own. of course, Rust also has the
> command-line equivalents of -fwrapv and -ftrapv, but that means that "what +
> does" depends on context, which isn't the choice i would have made. i suspect
> this is leads to every file starting with the moral equivalent of Perl's `use
> strict` cruft.)

Lots of people who've never used swift and rust believe them to be superior to
"C/C++", yes. :)

My position is there's no such thing as "C/C++": C is a good language, C++ is a
bad language, they are not remotely the same thing. Unfortunately C++ developers
have strategically blurred the distinction between them as a marketing strategy
since the 1980s, and yes I agree there's a nonzero chance that C++'s marketing
strategy will ultimately drag C down with it, which is sad. But not yet a certainty.

>From day one C++'s marketing message has insisted that C++ contains the whole of
C (it merely adds things to it) so MUST be just as good a language as C is, the
same way a mud pie contains an entire glass of water (merely adding stuff to it)
and thus must be just as good a beverage. It was wrong then and remains wrong
now, but C++ repeatedly doubles down on it as:

  https://en.wikipedia.org/wiki/Instinctive_drowning_response#Danger_to_rescuer
  https://en.wikipedia.org/wiki/Death_grip

C has minimal abstraction, everything is done manually and is the programmer's
fault, therefore it is possible for a programmer to understand what the code is
doing. It is "cooking with knives and fire" from raw ingredients that can give
you salmonella. Arguing "nobody should ever do that", and "only prepackaged food
can be safe"... is not how the world works? We make systems? Have inspections?
But people still Do The Thing, it didn't go away, as much as some people would
like it to:

  https://en.wikipedia.org/wiki/Electronics_right_to_repair

C++ is full of abstractions that do things for you behind the scenes, but you've
got to know how everything is implemented because the implementation details of
those abstractions leak to the surface. They keep piling thicker layers of
abstraction (like boost) on top, but it's never NOT going to leak implementation
details precisely because it's built on top of C, with pointers, static typing,
static allocation, static compilation, at least seven different memory
allocation contexts (stack, heap, environment, rodata, bss, text, mmap, and you
can have ALL of them in the same linked list). Their "contains the whole of C"
argument PREVENTS the abstractions from ever hiding the implementation details
except via "programmer discipline".

This is why I can still program in C99 (really C89: the only thing C99 added
that I cared about was uint32_t and friends and LP64 does it better), but C++
programs generally only support the most recent standard which C++ replaces
about every 3 years (11, 14, 17, 20...). I have a persistent problem that I
don't upgrade the OS version on my laptop often enough to build things written
in C++:

  https://landley.net/notes-2014.html#20-01-2014
  https://landley.net/notes-2018.html#13-11-2018

Apparently they're getting some pushback though? LLVM's planned move to C++17:

  https://www.phoronix.com/scan.php?page=news_item&px=LLVM-CPP17-2019

Doesn't seem to be what the CMakeLists.txt in github are checking for in the
current github llvm or clang directories? (I haven't been following it closely
since I can't build it on my laptop anyway because my cmake is too old.)

The "we should use higher level languages" thing is really an argument for
building more things in scripting languages like python (dynamic memory, dynamic
typing, dynamic compilation from source)... although the python 2.x->3.x switch
was a big enough disaster it too has developed the compiler version shelf life
problem. Not just "you need 3.x" but "a 3.x from 2017 is unusable in 2020":

  https://github.com/qemu/qemu/commit/1b11f28d0512

*shrug* The kernel is growing rust dependencies like it's grew BPF dependencies
and is re-growing perl dependencies:

  http://lkml.iu.edu/hypermail/linux/kernel/2105.2/02904.html
  http://lkml.iu.edu/hypermail/linux/kernel/2105.3/09273.html
  http://lkml.iu.edu/hypermail/linux/kernel/2106.0/00889.html

As long as they can keep extraneous dependencies out of the minimal core build I
acknowledge I can't defend the periphery. (My 2013 perl removal patch series
never took it out of the RAID code, for example. I never _removed_ openssl from
the kernel build, just figured out how to build without it)

Rob