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>
As 444 and 555 seem to be used for no apparent reason, use the more
conventional 644 and 755.
/man is typically unused or a symlink to /share/man now, so just use
/share/man.
Signed-off-by: JL2210 <larrowe.semaj11@gmail.com>
Note: I wanted to enable `-Og` on `develop`, but this generated warnings
(thus, errors) that aren't in `-O0`. Needs further investigation, but
annoyingly some of those are within `extern/` code, thus requiring
different flags, which AFAIK is only possible (sanely) with GNU Make.
This reverts commit 06fe27c516.
According to Microsoft's documentation
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tmpfile?view=vs-2019
`tmpfile` attempts to create the temporary file at the **root** folder
This seems to assume that the user has admin rights; might be a compat
thing, idk, but it breaks on people's computers.
(CI didn't catch it, annoyingly.)
Reverting to make RGBASM usable on most Windows computers.
(Sanely-configured ones, at least.)
Another solution to #446 needs to be figured out, yay...
