Remove the method for adjusting the count later, and instead store the
list in a PHYSFSX_uncounted_list until the count is available, then move
it into the PHYSFSX_counted_list along with the count. This prevents
using a list with its count unset.
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.
The standard type imposes some additional requirements that are not
necessary here, but using this concept allows standard containers to be
classified correctly without specific overrides.
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.
Since this should never be invoked, simplify the definition. The new
version is slightly less informative in case a logic error causes it to
be called, but is far shorter and easier to understand.
Win32 aliases `size_t` to `unsigned int`, causing
`static_cast<size_t>(V)` to be a useless cast when `V` has type
`unsigned int`. Switch to using direct initialization, which is not a
cast and so does not trigger a warning, but does produce the correct
type. This form disallows narrowing, so inputs that might change in
value as a result of the conversion are an error. Since this is a
sanity checking macro, that is a useful safety measure.
Reported-by: AlumiuN <https://github.com/dxx-rebirth/dxx-rebirth/issues/678#issue-1437577368>
The Rebirth main screen grd_curscreen borrows the memory allocated by
SDL_CreateRGBSurface to store its data. Store the pointer to that
surface inside grd_curscreen and make grd_curscreen responsible for
freeing the surface.
OS X still uses clang-14, which lacks sufficient std::ranges support for
recent Rebirth changes.
- Rewrite uses of std::ranges::SYMBOL to ranges::SYMBOL
- Add a stub header that, on gcc, provides for each SYMBOL a statement
`using std::ranges::SYMBOL;`, to delegate back to the standard library
implementation.
- On clang, define a minimal implementation of the required symbols,
without constraint enforcement. Compile-testing with gcc will catch
constraint violations.
Once OS X clang ships a standard library with the required features,
this stub header will be removed and the uses changed back to their full
names.
Adding `final` can allow gcc to devirtualize a call. Request compiler
warnings wherever `final` would improve this. As of this writing, there
are no places where `final` would be helpful and would also be wrong, so
this is enabled everywhere.
VR requires glDrawBuffer, which Mesa OpenGL ES does not offer. Default
VR to disabled for OpenGL ES users. Users who want to try it anyway can
still set use_stereo_render=1 in the SCons environment.
std::ranges::range<T> requires that T provide a reasonable `end()`.
cstring_tie did not provide one since it uses private inheritance of
`std::array`. However, it can provide a reasonable one, so define that
here.
`std::size_t` is `unsigned int` on i686-pc-linux-gnu, but is `unsigned
long` on x86_64-pc-linux-gnu. This mismatch allows d_array<E =
std::size_t> to be well-formed on x86_64, but trigger a duplicate
definition of operator[](E) on i686. Add a requires() check that
forbids both types for E, so that code which would break the i686 build
is also diagnosed in the x86_64 build.