* Opt into POSIX functions with `_POSIX_C_SOURCE` before any system
headers are `#include`d
* Allow user to override `make develop`'s `WARNFLAGS` and `CXXFLAGS`
* Use `make develop` on 32-bit Cygwin with sanitizers disabled
* Do not unnecessarily redefine `fseek` and `ftell`
* Disable a false-positive `-Wno-null-dereference` on 32-bit Cygwin
Co-authored-by: ISSOtm <[email protected]>
Since we build in a different configuration, it's plausible that some
warnings would only surface in Release (optimised) builds.
That should be an immediate blocker, so let's make it fail loudly.
Follow-up to 306a83a4, actually fixing the release script (oops!)
but also propagating the change to other release artifacts,
since unlike the regression testing workflows, we make the archives ourselves.
* Escape special characters in filenames when comparing gfx .err output
* Use `if` instead of `&&`
* Use `case` instead of `if` disjunction
---------
Co-authored-by: Eldred Habert <[email protected]>
Interestingly, Clang's `-Wformat-overflow` seems to only warn
about buffers so small they will *always* underflow,
whereas GCC tries to infer whether they can overflow *at all*.
(I'm guessing they lean towards false-negatives and false-positives resp.)
Anyway, calling `sprintf` here remains safe, since GCC (notably, via CI)
checks our work, and it simplifies the code ever so slightly while
also providing an (admittedly negligible) performance improvement.
Note that there may be more locations where we could use `sprintf`,
but a cursory glance at our other uses of `snprintf` didn't seem fruitful.
(One way to test is to set the target buffer size to 1, and see if a
warning pops up for such a trivially-wrong size. If not, you can be certain
the compiler won't be able to help you with a more realistic size.)
Massively simplified, by not trying to shoehorn differently-behaving
cases into the same one loop!
This may have introduced bugs (the test suite has caught three different
oversights, two of which via external projects, in fact!), but this also
makes the logic clearer and more streamlined, so that we are also less
likely to have any latent or future bugs.
In particular, previously, the first iteration of the loop could attempt
placement at an address not matching the section's constraints,
which made advancing to the next target address unnecessarily complicated
(https://github.com/gbdev/rgbds/pull/2064#discussion_r3985466596),
among other weirdness. The code ended up being defensive, and thus the
overall logic was murky.
I'm also expecting that this should provide a performance improvement due
to being essentially a form of loop-invariant code motion (and very likely
one a compiler couldn't have performed automatically), though I haven't
measured.
Fixes#2095
This code pre-dates the introduction of alignment offsets,
so it was never updated to take it into account.
That said, some of the code that I have factored out is a little awkward because
it will be used in an upcoming refactoring of the whole assignment loop,
since that turns out to be more byzantine than it ought to be due to
trying to handle a too disparate set of cases in a single loop.
Turns out the checks could fail spuriously if the starting alignment is non-zero,
e.g. `align 8,$C0` in HRAM. (Fixes #2113.)
This was tripped up by a test added to exercise the linker's section placement algorithm
on a similar aligment-related issue. :D
Note that this may be caused by the code in question pre-dating alignment offsets,
and we never checked. That said, these checks only work due to the regions' starting
addresses being no more aligned than their size (..if that makes sense?), so allowing
custom memory regions (#524) could violate that assumption and make those checks incorrect.
Assembling is never *supposed* to fail, but in this case I ended up adding
a test case that triggered a bug in the assembler, and that caused the rest
of the test to become garbled. This is thus more robust.
Rangi42
Rangi
Eldred Habert