Build fixes for GCC 15.3 and PUC Lua 5.1.5 - #6
Conversation
The existing construct is very dubious, since it creates a std::string temporary and then takes it by reference. GCC warns about it, and it may be UB.
I didn't investigate this deeply, so for now I just commented out the function in question.
Silences a warning with recent GCCs that default to C++20.
tile_color has a constructor so this isn't valid. Fix memset() by simply providing a default constructor that zero-initializes. Fix memcpy() by hand-writing a copy loop that uses the copy assignment operator.
There's two issues. First, the returned reference from the copy assignment operator must not be const. Second, the intention of the existing definition is to define a default copy assignment operator, so just use that.
|
Thank you! I'll take a look at these when I get a chance. |
|
I should explain that by and large we duplicate vanilla crawl's commits when we can and where we don't disagree about gameplay - for example for the first change in "Correct range-for loops that take a value rather than a reference" (and probably some more!) I've dug up vanilla commit ebf84c8 "Fix inadvertent copies in loops" and will apply that (but also changing any extra ones you found). This makes it easier to keep taking their changes when we want to (something that happens very slowly). This presents a bit of a problem when, for example, the vanilla commit that eliminates luaL_openlib has a whole lot of other non-gameplay commits it depends on. Hence a) thanks for letting me know where to look to eliminate these build errors / warnings b) I fear I probably won't apply the PR but will knock them out by other means (and hence sorry for unnecessary effort on your part) c) this could take a few days but d) I'll be most grateful if you will check again when I'm done since none of us has such an up to date build system (maybe I should do something about that). |
|
No worry, your approach makes perfect sense to me and is likely what I would be doing in your situation. Minimizing divergence from upstream is the right approach for maintenance. Thank you for the explanation, and I will be happy to check over the changes that you make when you complete them. |
|
I got a chance to have a look at this. (The forks tournament kicked up a certain number of bugs and other infelicities). I've got a mix of doing what you did (especially for "Replace deprecated Lua API luaL_openlib() with luaL_register()" where, sigh, after digging through a lot of earlier vanilla commits it turned out too hard to do it their way) and doing what vanilla did. cap_mutation_at() was added to tags.cc for a vanilla mutation change we didn't like. I left it around because I might want it later but I guess it's best to #if 0 it out and suppress the warning. The "tool/tile: Don't use memset() and memcpy() on array of tile_color" code seems unchanged in vanilla; IDK if you are sending them a PR as well. I have pushed a "compilefix" branch which has all the changes I have made as a result of this PR and would appreciate it if you'd let me know what I screwed up. Thanks. |
|
The "compilefix" branch builds cleanly for me (with TILES=y and gcc (Gentoo 15.3.0 p8) 15.3.0) and the contents of the commits all look good when I examined them. I think you've done a fine job. I haven't submitted "tool/tile: Don't use memset() and memcpy() on array of tile_color" upstream yet, but I just checked and it also looks to me that vanilla could use a trivial variant of that patch. I'll send vanilla a PR for it. |
|
Thank you. (I am very muddling through, knowing only NetHack pre-ANSI C before starting on Stoat Soup, so I'm a bit at sea with this kind of thing). I'll close this for now but I daresay more of this kind of thing will crop up and when it does I'll be grateful for help. |
These are a small pile of mostly trivial fixes I had to make in order to build Stoat Soup on an up-to-date, mostly-stable amd64 Gentoo install.
The update from luaL_openlib() to luaL_register() is to stop using a long-deprecated API that is removed in Lua 5.1.5 and perhaps prior versions. Stoat Soup fails to build for me without this commit applied.
The other commits are to silence warnings that often point to invalid or deprecated C++ constructs. There are eight of these commits because I've broken them out to make them easier to verify as being correct.
With all of these commits applied, Stoat Soup builds for me with no warnings.
No AI was used for any of these commits.