Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to v1.23 #300

Merged
merged 51 commits into from
Apr 15, 2023
Merged

Update to v1.23 #300

merged 51 commits into from
Apr 15, 2023

Conversation

javierdlr
Copy link
Contributor

updated amigaos4 SDLPoP with latest main v1.23 changes.

Adrien Humiliere and others added 30 commits April 8, 2018 09:47
…ystems without haptic support (SDL >= 2.0.9)
Tell Windows that SDLPoP is DPI aware to prevent unwanted stretching
Added more detail to MacOS developer section of the readme.
Fix linker error when building with newer clang
Expand buffer size to account for drawn_room type size.

screenshot.c: In function ‘draw_extras’:
screenshot.c:368:40: warning: ‘%d’ directive output may be truncated writing between 1 and 5 bytes into a region of size 4 [-Wformat-truncation=]
  368 |  snprintf(room_num, sizeof(room_num), "%d", drawn_room);
      |                                        ^~
screenshot.c:368:39: note: directive argument in the range [0, 65535]
  368 |  snprintf(room_num, sizeof(room_num), "%d", drawn_room);
      |                                       ^~~~
screenshot.c:368:2: note: ‘snprintf’ output between 2 and 6 bytes into a destination of size 4
  368 |  snprintf(room_num, sizeof(room_num), "%d", drawn_room);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With modern GCC, the string trunction checks point out that it's
technically possible to hit large paths that would get truncated. Add
explicit checks to both silence the compiler warning and actually validate
the snprintf() results.

options.c: In function ‘check_mod_param’:
options.c:455:3: warning: ‘strncpy’ specified bound 256 equals destination size [-Wstringop-truncation]
  455 |   strncpy(levelset_name, mod_param, sizeof(levelset_name));
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
options.c: In function ‘load_mod_options’:
options.c:680:50: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size between 0 and 255 [-Wformat-truncation=]
  680 |   snprintf(folder_name, sizeof(folder_name), "%s/%s", mods_folder, levelset_name);
      |                                                  ^~                ~~~~~~~~~~~~~
options.c:680:3: note: ‘snprintf’ output between 2 and 512 bytes into a destination of size 256
  680 |   snprintf(folder_name, sizeof(folder_name), "%s/%s", mods_folder, levelset_name);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
options.c:688:5: warning: ‘strncpy’ specified bound 256 equals destination size [-Wstringop-truncation]
  688 |     strncpy(mod_data_path, located_folder_name, sizeof(mod_data_path));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Also refactor the strncpy() uses into snprintf_check(). Overflows
from strncpy() would have resulted in a buggy behavior on overflow
(no %NUL terminator):

options.c: In function ‘load_mod_options’:
options.c:688:5: warning: ‘strncpy’ specified bound 256 equals destination size [-Wstringop-truncation]
  688 |     strncpy(mod_data_path, located_folder_name, sizeof(mod_data_path));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to make it easier to build SDLPoP for a distribution, extract
common CFLAGS, add -D_GNU_SOURCE globally, and split out CPPFLAGS
from CFLAGS. This split isn't perfect, though, since pkg-config doesn't
separate CPPFLAGS from CFLAGS, but it's good enough to get dpkg-buildflags
exports recognized for the build:

$ dpkg-buildflags --export=sh
export CFLAGS="-g -O2 -fdebug-prefix-map=/home/kees/src/SDLPoP=. -fstack-protector-strong -Wformat -Werror=format-security"
export CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2"
...
kees and others added 20 commits June 20, 2020 12:03
Check for short fread() (and silence warnings under -Wunused-result
and -D_FORTIFY_SOURCE=2).

menu.c: In function ‘calculate_exe_crc’:
menu.c:2050:5: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
 2050 |     fread(buffer, 1, (size_t)size, exe_file);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check for short fread() and fscanf() (and silence warnings under
-Wunused-result and -D_FORTIFY_SOURCE=2).

options.c: In function ‘ini_load’:
options.c:69:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   69 |   fscanf(f, " ;%*[^\n]");
      |   ^~~~~~~~~~~~~~~~~~~~~~
options.c:70:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   70 |   fscanf(f, " \n");
      |   ^~~~~~~~~~~~~~~~
options.c: In function ‘load_dos_exe_modifications’:
options.c:524:3: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
  524 |   fread(exe_memory, (size_t) info.st_size, 1, fp);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead of open-coded image numbers, positions, etc, in the code, move
all the values into a common data structure, and use an enum to identify
what needs drawing.
Replace README.md by a symbolic link to doc/readme.txt
Support for SDL_GameControllerRumble() and SDL_JoystickRumble()
So they appear correctly as MarkDown (see NagyD#171).
Handle more error conditions and eliminate build warnings
updated makefile to be able to build with latest amigaos4 libFLAC (1.4.2 - 08 Mar 2023)
Updated to 1.23 version files (no amiga code involved)
Updated to 1.23 version files (amigaos changes involved)
@javierdlr
Copy link
Contributor Author

javierdlr commented Apr 10, 2023

Ooops forget it just found I did pull to wrong branch :-(
Think I changed to the correct branch (amigaos4)

@javierdlr javierdlr changed the base branch from master to amigaos4 April 10, 2023 09:36
@NagyD NagyD merged commit 8fdc560 into NagyD:amigaos4 Apr 15, 2023
@NagyD
Copy link
Owner

NagyD commented Apr 15, 2023

This gave me loads of merge conflicts.
I went through them all by hand to ensure all merges are done right, and still I got some compiler errors after I committed the merge.

In the long term it would be better if I could merge amigaos4 into master, and the same source could be compiled for all systems.

NagyD added a commit that referenced this pull request Apr 15, 2023
NagyD added a commit that referenced this pull request Apr 15, 2023
Merge AmigaOS-specific changes into master, so the same source can be used for all systems. (#300)
@NagyD
Copy link
Owner

NagyD commented Apr 15, 2023

Okay, I have merged amigaos4 into master.
I have verified that it compiles and runs correctly on Windows.
Could you verify the same on AmigaOS?

NagyD added a commit that referenced this pull request Apr 15, 2023
@javierdlr
Copy link
Contributor Author

1st sorry for answering so late.
2nd sorry for all the hassle while merging amigaos4<->master

Downloaded and build/mAKE amigaos4 works, but I have to add some defines in makefile.amigaos4, will send it ASAP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants