Use reserved bytes in OSThread structs for wut related thread specifics #323
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Open for discussion.
Recently
__wut_getreent
got implemented which usesOSGetThreadSpecific
/OSSetThreadSpecific
to store some thread specific data. This works fine for regular homebrew, but for WUPS/WUMS (Plugin/Module system) we might end up using a reent within a (Cafe OS) thread we do not control (e.g. due to function replacing/patching). In this case using/overriding the "regular" thread specifics might then result in undefined behaviour. To avoid this I propose to the use the "reserved" bytes of the OSThread struct for custom thread specifics which are exclusively reserved for wut.Contra:
Pro:
getreent
implementations for WUPS/WUMS.I am personally not really sure how to fix it. Using these reserved bytes feels indeed very hacky but seems overall to be the easiest and cleanest solution.