-
Notifications
You must be signed in to change notification settings - Fork 447
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
Enable -Wint-conversion
warning
#1266
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of this in principle but we need to decide what to do with rom addresses and segmented addresses first, I think. I have a few comments on the current state, mostly where one or the other cast seems better.
@@ -102,8 +102,8 @@ endif | |||
|
|||
# Check code syntax with host compiler | |||
ifneq ($(RUN_CC_CHECK),0) | |||
CHECK_WARNINGS := -Wall -Wextra -Wno-format-security -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-variable -Wno-missing-braces -Wno-int-conversion -Wno-unused-but-set-variable -Wno-unused-label -Wno-sign-compare -Wno-tautological-compare |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you also removed -Wno-format-security, what does that imply?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does nothing currently. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-security
It warns you for cases when you misuse printf/scanf functions, like passing a float when you have a %u
We could annotate some variadic functions that work similar to printf (with __attribute__ ((format (printf, 2, 3)))
) but that's a out of scope for this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a confusing attribute. Yeah, don't think we need to worry about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to link the docs about it
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
I think it could actually be useful in the future
src/boot_O2/system_heap.c
Outdated
typedef void (*BlockFunc8)(void*, u32, u32, u32, u32, u32, u32, u32, u32); | ||
typedef void (*BlockFunc)(uintptr_t); | ||
typedef void (*BlockFunc1)(uintptr_t, u32); | ||
typedef void (*BlockFunc8)(uintptr_t, u32, u32, u32, u32, u32, u32, u32, u32); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I will note with these functions is this is what happens in OoT N64: https://decomp.me/scratch/0cnK7 , which might affect how we want to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what I'm supposed to look at
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point is that the casting will surely follow the same pattern, so if there's discrepancy it's probably wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe they got reworked like a lot of stuff between OoT and MM? 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only reworking I see there is the interrupt handling is removed for MM and OoT GC.
@@ -1438,7 +1438,7 @@ void AudioHeap_ApplySampleBankCacheInternal(s32 apply, s32 sampleBankId) { | |||
|
|||
sampleBankTable = gAudioCtx.sampleBankTable; | |||
numFonts = gAudioCtx.soundFontTable->numEntries; | |||
change.oldAddr = AudioHeap_SearchCaches(SAMPLE_TABLE, CACHE_EITHER, sampleBankId); | |||
change.oldAddr = (uintptr_t)AudioHeap_SearchCaches(SAMPLE_TABLE, CACHE_EITHER, sampleBankId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I defer to @engineer124 on all the audio stuff in here, most of these structs are quite deep.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admittedly, low level audio does a lot of weird pointer manipulation with offsets and indexing when both transferring audio assets from rom to ram (sequences/soundfonts/samples), and even more weird pointer/offset math when extracting meaningful information from it (especially soundfonts, that's really messy when it comes to pointers).
Given that, I think I'd need to sit down and summarize all the pointer math involved in audio and share that to figure out what kind of types we need. That would take time though, so for now I think I'm fine with just making sure it's consistent i.e. warning free?
@@ -32,7 +32,7 @@ void* THA_GetTail(TwoHeadArena* tha) { | |||
void* THA_AllocHead(TwoHeadArena* tha, size_t size) { | |||
void* start = tha->head; | |||
|
|||
tha->head = (u8*)tha->head + size; | |||
tha->head = (void*)((uintptr_t)tha->head + size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really see the point of casting out of and back into a pointer here when it's not necessary, (u8*) just seems better for this sort of arithmetic where possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I see doing pointer arithmetic as something bad and which should be avoided. That's why we have types to do proper pointer arithmetic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this is standard pointer arithmetic, not alignment, it's not an unusual operation. Arithmetic is one of the two main properties of pointers, after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Casting to uintptr_t
to perform pointer arithmetic is way more common in the codebase than using u8*
@@ -103,7 +103,7 @@ void* THA_AllocTailAlign(TwoHeadArena* tha, size_t size, uintptr_t mask) { | |||
* @return Remaining size. A negative number indicates an overflow. | |||
*/ | |||
s32 THA_GetRemaining(TwoHeadArena* tha) { | |||
return (s32)((u8*)tha->tail - (u8*)tha->head); | |||
return (uintptr_t)tha->tail - (uintptr_t)tha->head; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually won't this output an unsigned thing that then gets cast? I think keeping it as u8* is a much better option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't keep this as u8*
without casting somewhere, that's the point of -Wint-conversion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So cast to the return type afterwards.
@@ -39,8 +39,7 @@ void Font_LoadOrderedFont(Font* font) { | |||
loadOffset = 0; | |||
} | |||
|
|||
DmaMgr_SendRequest0(writeLocation, (uintptr_t)SEGMENT_ROM_START(nes_font_static) + loadOffset, | |||
FONT_CHAR_TEX_SIZE); | |||
DmaMgr_SendRequest0(writeLocation, SEGMENT_ROM_START(nes_font_static) + loadOffset, FONT_CHAR_TEX_SIZE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So does SEGMENT_ROM_START_OFFSET work here or not? Either way I think it confuses the operation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weirdly no, this place requires the cast to happen before the arithmetic and not before. The devs were definitely not consistent with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple more nits though overall LGTM. Does seem good to enable this warning.
Co-authored-by: Derek Hensley <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admittedly, I don't know if all of Elliptic's concerns were fully addressed, but this has been open for months. I think it's better for us to get this in and fix things later.
if ((objectSlot > OBJECT_SLOT_NONE) && (Object_IsLoaded(&play->objectCtx, objectSlot))) { | ||
void* segBackup = gSegments[6]; | ||
if ((objectSlot >= 0) && (Object_IsLoaded(&play->objectCtx, objectSlot))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bad merge. Could you bring back OBJECT_SLOT_NONE
and remove the extra brackets around Object_IsLoaded
Turning this warning on makes CC_CHECK to warn about implicit int/pointer conversions, to avoid it we just need to make a explicit cast.
uintptr_t
as much as I can (as we mostly do already)uintptr_t
cast in theSEGMENT_ROM_START
/SEGMENT_ROM_END
macrosSEGMENT_ROM_START_OFFSET
macro because some places in the codebase do arithmetic with au8*
pointer and doesn't like the address to be casted touintptr_t
before the arithmetic. Same reason forSEGMENT_ROM_SIZE2
.