From rogerman:
The RomBanner struct requires UTF-16 strings for the six different ROM titles.
Currently, we use wchar_t buffers to define the memory blocks where the title
strings are supposed to go. Using wchar_t is fine for compilers that assume a
2-byte wchar_t. But compilers that use a 4-byte wchar_t will misalign
the memory blocks.
I've submitted a new patch that changes all the wchar_t in RomBanner titles
to u16 for all ports. It took me a while to research the dependencies on
titles, and to make sure I didn't accidentally break something in the
Windows port.
As for the wcscpy() deal in the RomBanner constructor, it's an arbitrary
default init value that we don't actually use in practice, so I removed it.
If a particular port wants to know what to display for the titles when a
ROM isn't loaded, there are plenty of ways to figure this out. Or they can
just check the titles for an empty string, which the constructor inits the
titles to before the wcscpy() call.
For CHEATS::save(), I removed the dependency on using titles. The ROM name
we write to file is also an arbitrary value which we don't actually
reference in practice. I changed it to use gameInfo.ROMname, since we're
already using gameInfo.ROMserial.
Anthony J. Bentley reports that desmume does not compile
on OpenBSD when the hud is enabled in bug #3148356.
After a few he reports that Stuart Henderson of OpenBSD
found the problem. The macro definition of ALIGN() conflicts
with a definition in /usr/include/machine/param.h.
So rename ALIGN macro to DS_ALIGN.
When the user uses an external firmware image, there is a
call to getpathnoext() in firmware.cpp:571 in order to
generate a file name for the saved firmware config file.
The size of the MMU.fw.userfile char buffer is only 260,
as declared in mc.h:73. However, getpathnoext() expects
the buffer size to be MAX_PATH, which is declared as 1024
in types.h:77. The buffer overflow occurs in path.h:293
with the call to strncpy(), which copies 1024 chars into
MMU.fw.userfile, which is only 260 chars.
This patch fixes this bug by setting the MMU.fw.userfile
char buffer to a size of MAX_PATH. This is consistent with
the char buffers used for the other file names.
From rogerman, #3328686
NSMB gets one step further. When Luigi receives Mario's data frames, he tries to use port 094 (REPLY1) to respond, but only writes zero there for whatever reason.
mtabachenko