gcc-12 can issue `-Warray-bounds` warnings for code inlined from system
headers, and warns about `std::sort()` on a small array (
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986> split from
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165>). Per a comment
in a related Fedora report
<https://bugzilla.redhat.com/show_bug.cgi?id=2051783#c3>, and local
testing, adding an explicit unreachable on the impossible case that the
end iterator exceeds the end of the array will discourage gcc from
warning without needing to disable -Warray-bounds.
This failure was previously observed in early testing with gcc-12, and
was set aside in the hope that gcc-12 would be fixed before it came into
widespread use. That has not happened, and JoeNotCharles reported
<2644e0cb93>
this independently. JoeNotCharles proposed disabling the warning for
the call to `std::sort`. This commit instead leaves the warning
enabled, but encourages gcc to see that the bad path is impossible,
allowing gcc to delete the bad path before the warning is issued.
JoeNotCharles reports that gcc-12 (architecture unspecified) warns
because `newmenu::process_until_closed` stores the address of a stack
local into a heap-allocated structure. Switch to a less efficient
implementation that does not provoke a compiler warning:
- Store `shared_ptr<int>`, not `int *`, in the `newmenu`
- `shared_ptr::operator*()` and `shared_ptr::operator bool()` allow most
use sites to be unchanged relative to a bare pointer
- Load the return value from the `shared_ptr<int>`. If the newmenu
terminated before return, as should always happen, this is a slightly
less efficient version of the same code as before. If the newmenu was
still open despite its `exists` flag claiming otherwise, then the
returned value may be incorrect, but the read will be well-formed, the
`newmenu`'s eventual write will write to the heap-backed int (rather
than writing into the stack allocated to
`newmenu::process_until_closed`), and the memory will be freed when
both `process_until_closed` has returned and the `newmenu` has been
destroyed.
Reported-by: JoeNotCharles <10a2b2d337>
gcc-12 does enough escape analysis to notice that
newmenu::process_until_closed stores the address of a stack local into a
heap-allocated structure, but not enough analysis to notice that the
stack variable always outlives the escaped address. The compiler then
warns about the address escaping the local scope. Reworking the calling
code not to do this is somewhat invasive, and gcc seems unlikely to
change behavior. Switch to a less efficient implementation that does
not provoke a compiler warning:
- Store a shared_ptr<bool> in the object
- In the object's destructor, write through the pointer to clear the
shared boolean
- In the caller, store a copy of the shared_ptr<bool> as a local, and
use that copy to monitor the shared boolean
This is similar to a change proposed by JoeNotCharles
<10a2b2d337>,
but differs in its details. Among other things, this version takes the
opportunity to move the variable out to a mixin, so that only windows
which expect to be tracked can be tracked. Previously, all windows were
capable of this, even though most never needed it.
JoeNotCharles reported
<1f1903a3b9>
an overflow in `net_udp_send_mdata_direct`. This overflow is impossible
as currently written, because it can occur only if
`multi_send_data_direct` passes an oversized buffer to
`net_udp_send_mdata_direct`, and no messages are large enough to trigger
this. JoeNotCharles proposed adding a runtime check to abort the
program if this happens. Instead, this commit adds a compile-time check
to detect use of an excessively large input buffer.
JoeNotCharles reports that gcc-12 (architecture unspecified) warns about
a possible truncation when constructing a path. This would only occur
if the user had a path that was almost PATH_MAX deep (4096 bytes on most
platforms). Add safety checks around this, and around an underflow if
this path were somehow reached while `newpath` was shorter than `sep`.
This is loosely based on a proposed commit by JoeNotCharles, but
rewritten to update comments and adjust the code flow.
Reported-by: JoeNotCharles <edfb3c4b77>
Construct the nm_messagebox_tie directly, without use of a macro. This
produces simpler compiler error messages when nm_messagebox is called
incorrectly.
Per SDL documentation, SDL will generate an SDL_QUIT event when
Command-Q is used. Rebirth already handles SDL_QUIT, so there is no
need to explicitly detect Command-Q.
This allows the compiler to see and perform basic checks on the call
even in builds with `DXX_WORDS_NEED_ALIGNMENT == 0`.
Also, fix a missing address-of operator in one invocation of
`align_polygon_model_data`.
Reported-by: Brunnis <https://github.com/dxx-rebirth/dxx-rebirth/issues/687> (missing address-of operator)
Fixes: 43e1c841f0 ("Pass polymodel& to polymodel_read")
Switch from using a macro to capture __FILE__,__LINE__ to using
__builtin_FILE(),__builtin_LINE(). Make the event an explicit argument,
instead of assuming it is a variable named `event`. Move the
implementation out of line.
When building with -D_GLIBCXX_DEBUG, gcc-11 warns:
```
In file included from /usr/include/string.h:535,
from similar/main/net_udp.cpp:14:
In function 'void* memcpy(void*, const void*, size_t)',
inlined from 'virtual void d2x::multi::udp::dispatch_table::send_data_direct(std::span<const unsigned char>, dcx::playernum_t, int) const' at similar/main/net_udp.cpp:5731:8:
/usr/include/bits/string_fortified.h:29:33: error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
```
The warning is invalid: the destination buffer is not PTRDIFF_MAX bytes
long, and the requested length is not SIZE_MAX bytes. Both claimed
lengths are the result of excessively cautious value range tracking.
Eliminate the warning by adding a `cf_assert` to assure gcc that
`data.size() != std::dynamic_extent`.