You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Far too many warnings-as-errors to count or list here. They generally fall into a few groups though:
Attempting to initialize complex data types (non-trivial structs/classes) to zero-data via memset(). The warnings can be made to go away by doing a forcible reinterpret_cast<void*>() on the destination pointer, but that may leave some objects initialized incorrectly in some cases.
Developers not understanding how if or case syntax works in C++ and trying to rely on non-brace-enclosed indentation, or multiple statements on one line, to gate the behavior of multiple statements by way of a single if conditional. In some cases there are obvious defects (and adding braces is clearly the right thing to do), while in other cases it's unclear whether the dev was intending for the indentation to have a logical effect or whether they were just using as a wonky way of formatting per their personal preferences. Fixing all of these accurately will require deep knowledge of the original author's intent in many cases.
Bad calls to strncpy() or memset() that provide obviously-questionable-or-wrong length parameter values. Most of these seem pretty straightforward to fix.
I've been working my way through manually fixing as many as I can, just to get the build to work, but my fixes for some of them have been non-trivial change that may conflict with future changes from upstream. Looking for guidance on the right approach to fixing each of the above issues without introducing too much conflict.
The text was updated successfully, but these errors were encountered:
c0d3h4x0r
changed the title
numerous warnings-as-errors build failures under MSYS2 on Windows 10
compilation failures with gcc 9.2.0 (numerous warnings-as-errors building on Win10 using msys64)
Mar 3, 2020
It looks like the real problem is lack of clear instructions about how to build this libretro core. Apparently you need to use the command make -f Makefile.libretro rather than just make, so that it picks up and uses the libretro-specific Makefile -- which, among other things, disables warnings-as-errors.
That said, I've definitely found and fixed some code defects while working my way through properly resolving all the warnings, so we should keep this issue open to track picking up those fixes if nothing else. I'm gradually working on a merge request in my spare time.
Possibly a dup of #8 but not sure.
Far too many warnings-as-errors to count or list here. They generally fall into a few groups though:
Attempting to initialize complex data types (non-trivial structs/classes) to zero-data via
memset()
. The warnings can be made to go away by doing a forciblereinterpret_cast<void*>()
on the destination pointer, but that may leave some objects initialized incorrectly in some cases.Developers not understanding how
if
orcase
syntax works in C++ and trying to rely on non-brace-enclosed indentation, or multiple statements on one line, to gate the behavior of multiple statements by way of a singleif
conditional. In some cases there are obvious defects (and adding braces is clearly the right thing to do), while in other cases it's unclear whether the dev was intending for the indentation to have a logical effect or whether they were just using as a wonky way of formatting per their personal preferences. Fixing all of these accurately will require deep knowledge of the original author's intent in many cases.Bad calls to
strncpy()
ormemset()
that provide obviously-questionable-or-wronglength
parameter values. Most of these seem pretty straightforward to fix.I've been working my way through manually fixing as many as I can, just to get the build to work, but my fixes for some of them have been non-trivial change that may conflict with future changes from upstream. Looking for guidance on the right approach to fixing each of the above issues without introducing too much conflict.
The text was updated successfully, but these errors were encountered: