This should hopefully work torwards compatibility with more systems.
I've tried to make this as general as possible but some small assumptions
about the compiler are made. I've also tried to recreate the build process
as closely as possible, but I had to change some things slightly to work
with CMake (version strings, mainly).
For now, it doesn't allow in-source builds, as that could overwrite the
Makefile.
This adds:
- Support for more build systems
- Automatic dependency generation
- Performance gains (especially when using i.e. Ninja)
Defaults to Release build.
This one's really stupid; printing an int with %hhu gives a warning
even though a regular unsigned char is promoted to an int before
printing anyway. Silence it so the build with Clang works.
This is a regression introduced in 5c24de3
GCC with the -std=c11 defines __STRICT_ANSI__. DJGPP checks if
__STRICT_ANSI__ is defined and if so doesn't define some things
mandated by POSIX such as struct stat, PATH_MAX, and others.
The -std=gnu11 option does not define this macro, so use it instead.
_DEFAULT_SOURCE isn't needed as no GNU nor BSD-specific functions
are used. Remove it.
Fix the last two occurrences of incorrect format specifiers for standard
fixed-width integer types.
`macro_GetArg` had not been changed after the previous commit; however,
the old code relied on the `macroArgs->args` array being at least
`MAXMACROARGS` entries large (which was the case until the last commit).
The boundary against which it checked would have better been written as
`sizeof(macroArgs->args)/sizeof(macroArgs->args[0])`, I guess, but what's
done is done.
This should help make RGBDS portable to systems with 16-bit integers,
like DOS.
For kicks, use the macros for 16-bit and 8-bit integers.
Fix other miscellaneous things, like #include ordering and other
printf-format related things.
Reduce repitition in math.c while I'm there.
This didn't break unless the first uninitialized byte was non-zero,
which happened to be the case on someone's Windows machine.
Would it be worth it setting up Valgrind in CI?
Fixes#307
RGBFIX can handle padding, so there's no reason why
we can't add an option to disable padding in rgblink.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
It's possible that tile could be leaked, so free it.
Fix sizeof convention and check the result of malloc.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
This includes not checking the result of malloc and
using the wrong type in sizeof. Only the latter was
caught by scan-build.
Also use more idiomatic sizeof().
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
It's possible that the unsigned integer may overflow to zero,
and then we might use zero-allocated memory.
This is incredibly unlikely, and I would even go so far as to say
that this is a false positive. Fix it anyway, to silence this warning:
src/link/patch.c:92:24: warning: Use of zero-allocated memory
stack.buf[stack.size] = value;
~~~~~~~~~~~~~~~~~~~~~ ^
Deal with overflow, and check for zero to get rid of the warning.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
Yet another case caught by scan-build:
src/link/patch.c:188:21: warning: Division by zero
value = popRPN() % value;
~~~~~~~~~^~~~~~~
Just copy over the code from the division case, with a few modifications.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
It's possible that if the FILE passed to yy_create_buffer is at the
end-of file, there may be a null pointer dereference.
This should hopefully fix that.
Found with clang-tools' scan-build:
src/asm/lexer.c:281:25: warning: Array access (via field 'pBuffer')
results in a null pointer dereference
pBuffer->pBuffer[size] = 0;
~~~~~~~ ^
1 warning generated.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
