"fixed" and "aligned" location checking advanced the target location to places
regardless of the associated free space, potentially breaking the assumption
that the location was always further in memory than the free space's base.
Rather than adding more code to try keeping that assumption true, harden
`isLocationSuitable` and handle that case as well.
Windows does not honor `%F` nor `%T` in `strftime`. These are worked around
by writing the full format they serve as a short for.
However, Windows also treats `%z` and `%Z` identically, where SUS instead
requires `%z` to output a ±XXXX offset.
Since the current information is broken (no information), this isn't *breaking*
anything, but at least provides something a human will probably understand.
`__ISO_8601_UTC__` is unaffected because it hardcodes the timezone character,
only `__ISO_8601_LOCAL__` suffers from this.
Fixes rednex/#446.
I am not sure this is the best (in cases where the target directory
is not writable but the target file is), but maybe this can be
toggled via a flag, for example.
This option allows for automatic dependency detection and generation:
as soon as a missing file is found, it is output to the dep file, and
assembly immediately aborts. (No .o file is produced, even if `-o` was
speicified.) This doesn't cause an error, either; the point is that once
the file is added to the dep file, the Makefile is re-parsed, and this
time the file will be generated, so the dep list builds up automatically.
This mimicks GCC's option and behavior.
Allows overriding the output file in dependencies, which also allows
outputting those without also outputting the object file.
This, again, mimicks GCC's option.
Stop using that bitfield for everything, including what can be determined otherwise
It also makes it easier to have a sane state, since some bits were (supposedly)
mutually exclusive
This is actually not necessary, because RGBLINK would warn about missing labels.
Besides, through semi-esoteric ways, it is possible to define more labels in this scope,
and there's no reason to prevent that.
`char` has implementation-defined signedness, and if it's chosen to be unsigned,
then -1 gets converted to 255, which is then promoted back to `int` as... 255,
always failing the loop condition in src/link/main.c:118
`int8_t` has the correct signedness, but considering `musl_getopt_long_only`
returns `int`, better use that so as not to lose any bits
