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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
