UI_DIALOG::event_handler's case `EVENT_WINDOW_CLOSE` can only be hit if
`rval == window_event_result::ignored`. Any other result returned
before entering the switch. If `rval == ignored`, then returning
`ignored` will cause `window_close` to delete the object. Delegate to
that deletion instead of having an explicit deletion in this handler.
Only trust the output of pkg-config if it exited success. Capture any
text sent to its stderr and reprint it, with decorations, to the screen
and to the log.
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>
std::ranges algorithms include requires() clauses that:
- rejected enumerated_sentinel: not default-constructible
- rejected enumerated_sentinel: not assignable due to `const` member
- rejected enumerated_iterator: no postfix operator++
None of these need to be satisfied for enumerate to work properly, but
this commit satisfies and models these requirements, so that future use
of std::ranges algorithms will work.
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.
The existing usage pattern of these variables - creating them on the
stack, passing a raw pointer to the window object, and then looping
until the window resets the variable - is safe, but triggers a lifetime
warning in GCC because the window object outlives the stack variable and
the compiler doesn't detect that the calling code never returns until
the window object is done with the variable.
Work around this by using a shared_ptr so the window keeps a reference
to the variable. This is also safer in case refactoring adds earlier
returns from the stack variable's scope.
If newpath ends in a directory separator, the EVENT_NEWMENU_SELECTED
handler appends another copy of the separate before appending
list[citem]. However the bounds check before snprintf didn't include the
extra separator, leading to a -Wformat-truncation warning.
The new resampler sets upFactor to either `2` (for 22Khz sounds) or
`4` (for 11Khz sounds). However, the logic to pick which coefficient
table to use tested for `0` versus non-zero, so it always picked the
coefficient table meant for 22Khz sounds, even when the sample was an
11Khz sound. This caused a high pitched ringing in sampled sounds.
Switch to use an `enum class` to prevent using zero-vs-nonzero tests
without a cast. Change the existing test to test for the 22Khz `enum`
value, as originally intended. In testing, this eliminated the ringing
effect in 11Khz sounds.
Identified-by: Chris <https://forum.zdoom.org/viewtopic.php?p=1234989> (in response to a request by KynikossDragonn)
Fixes: 5165efbc46 ("Use custom fixed-point audio resampler: - Hopefully fixes issues with poor quality resampling when using SDL_AudioCVT - Converts 11025 Hz or 22050 Hz samples to the default 44100 Hz outputs - Uses high order brick wall filter like Sound Blaster 16")
In any given run of the program, either the SDL_mixer code will be used,
or it will not be used. `digi_sample_rate` only needs to vary if a
single run both uses SDL_mixer and avoids it. Make `digi_sample_rate` a
`static const` with an appropriate value for each path.
Add the SDL_mixer-based resampler as a compile-time alternative, which
can be chosen by setting `-DDXX_FEATURE_INTERNAL_RESAMPLER=0`. Keep the
new internal resampler as the default.
