X Tutup
Skip to content

SCI: Improve reg_t initialization sequence#6638

Merged
bluegr merged 1 commit intoscummvm:masterfrom
orgads:sci-reg_t-init
May 28, 2025
Merged

SCI: Improve reg_t initialization sequence#6638
bluegr merged 1 commit intoscummvm:masterfrom
orgads:sci-reg_t-init

Conversation

@orgads
Copy link
Contributor

@orgads orgads commented May 19, 2025

  • A single function instead of call to setSegment and inline setOffset.
  • Checks SCI version only once.
  • Initializes _segment directly with both values instead of twice.
  • Fixes -Wmaybe-uninitialized GCC warning.

This reverts commit 33643c7.

* A single function instead of call to setSegment and inline setOffset.
* Checks SCI version only once.
* Initializes _segment directly with both values instead of twice.
* Fixes -Wmaybe-uninitialized GCC warning.

This reverts commit 33643c7.
@orgads orgads requested review from bluegr and sluicebox May 19, 2025 05:50
@bluegr
Copy link
Member

bluegr commented May 28, 2025

Looks good, thanks!

@bluegr bluegr merged commit 7693e08 into scummvm:master May 28, 2025
8 checks passed
@orgads orgads deleted the sci-reg_t-init branch May 28, 2025 18:32
@bluegr
Copy link
Member

bluegr commented May 28, 2025

Ugh. This wasn't tested at all - it crashes on startup. Will provide a proper fix.

@bluegr
Copy link
Member

bluegr commented May 28, 2025

Regression fixed in 80c635b

@orgads
Copy link
Contributor Author

orgads commented May 29, 2025

Ugh. This wasn't tested at all - it crashes on startup. Will provide a proper fix.

Just for the record - It was tested (and works) on release. The crash is a failed assertion, which only happens on debug build.

@bluegr
Copy link
Member

bluegr commented May 30, 2025

Ugh. This wasn't tested at all - it crashes on startup. Will provide a proper fix.

Just for the record - It was tested (and works) on release. The crash is a failed assertion, which only happens on debug build.

That assertion was triggered because SCI version isn't initialized before the engine starts. It's a fundamental issue. The fact that the assert isn't thrown in release builds doesn't mean much :)
The assert was thrown on ScummVM startup, so it was pretty obvious to spot

@orgads
Copy link
Contributor Author

orgads commented May 30, 2025

I understand, but for release build assert is no-op. Quoting the man page:

If the macro NDEBUG is defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all. It is not recommended to define NDEBUG if using assert() to detect error conditions since the software may behave non-deterministically.

@criezy
Copy link
Member

criezy commented May 30, 2025

I understand, but for release build assert is no-op. Quoting the man page:

That is not correct. assert is a no-op if NDEBUG is defined. But we do not define NDEBUG for release builds (except for a few exceptions such as the Atari port where the added performance of making it a no-op is noticeable). Defining NDEBUG for release builds was proposed and discussed in PR #2486, and was not merged in the end.

@orgads
Copy link
Contributor Author

orgads commented May 30, 2025

I understand, but for release build assert is no-op. Quoting the man page:

That is not correct. assert is a no-op if NDEBUG is defined. But we do not define NDEBUG for release builds (except for a few exceptions such as the Atari port where the added performance of making it a no-op is noticeable). Defining NDEBUG for release builds was proposed and discussed in PR #2486, and was not merged in the end.

It is correct for cmake apparently. I'll try to remove the flag.

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.

3 participants

X Tutup