rgbds: build of 0.5.1 fails

Then why not stick with rgbds 0.5.0? Sure it has known bugs and missing features, but so do bison 2 and other old packages. And it’s not like a Game Boy assembler is a necessary component for a Linux distro. (Especially since Sabotage Linux “refuses to add Rust”, and the rgbds ecosystem is increasingly using Rust, e.g. rgbobj and rsgbgfx.)

Also the first file I checked in strlib, containsChar.c, could have just been return strchr(str, what) != NULL. (Which doesn’t say much good about C’s built-in “string” (aka pointer to some bytes which we hope end in a ‘\0’) handling functions either.)

you’re looking in the wrong place, the string+size struct stuff is provided by src/stringptr - and the purpose of strlib is to pull in as little of libc as possible, to keep static binaries small (iirc the only libc funcs called are memcpy and malloc* - and the latter only if a *_new func is used)

However, If you just use C with classes and maybe with operator overloading and things like that… the result tends to be okay. Just avoid the C++ standard library… and almost every other library. I would use std::string and little else.

that’s true, but once C++ is being used, you’re automatically attracting C++ “wizards”, which will start opening PRs using their favorite feature subset… just as linus points out in that article.

I don’t plan on doing anything weird with class inheritance or templates (probably no need for templates at all, unless we have like three+ functions which are identical except for types). Feel free to critique PRs for being too C++ featureful if/when I work on that. 😛

I don’t know how far off a Rust rewrite is (that would be @ISSOtm 's project) but I’m considering starting a more gradual transition to C++, for the sake of using some of its features (in particular to unblock #885, but I expect RAII idioms will also make for cleaner code).

Not speaking for the other maintainers, but I don’t think being written in C adds any inherent value to rgbds, besides allowing well-optimized performance of native code (same as C++, Rust, Zig, Haskell, and many other languages) and being supported on “enough” platforms (anything with an LLVM backend is sufficiently portable here).

Drew DeVault may think that “concurrency is generally a bad thing” and that “Yes, Rust is more safe. I don’t really care.” but in practice C has been a cause of rgbds issues (use-after-free, buffer overflows, null-terminated strings, having to manually malloc/free, undefined behavior, etc) not a solution to them (yes, C has a spec and only “0.73 new features per year”; I don’t really care). (Even he is aware enough of C’s issues to be building a new systems language.)

I’m personally against making the parser file and the build process more complicated for the sake of supporting an eight-year-old bison version. macOS users should be used to upgrading various outdated built-in programs (IIRC they stick with some very old Linux utilities for license reasons), and Linux/BSD/etc users are capable of either patching parser.y to avoid bison 3 features, or patching the Makefile to use a local copy of bison 3. (I’m used to doing that myself with different rgbds versions for some old assembly projects.)

However, if we do end up adding a sed patching step, this could work:

• Update PR #923 to replace the "%left"s that it adds with “%bison2_left”
• In the Makefile, if the bison version is 3, use sed to remove all lines starting with “%bison2_left”
• If the bison version is 2, replace all “%bison2_left” with “%left”, replace all “%precedence” with “%left”, and remove all “%empty”

That would isolate most of the added complexity in the Makefile (or better, in a script called by the Makefile), and the extra "%bison2_left"s in parser.y would at least be self-explanatory.