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

Enable -Wint-conversion warning #1266

Merged
merged 62 commits into from
Nov 1, 2023
Merged

Conversation

AngheloAlf
Copy link
Collaborator

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.

  • For Physical/rom addresses I try to us uintptr_t as much as I can (as we mostly do already)
  • Because of the previous point, I added a uintptr_t cast in the SEGMENT_ROM_START/SEGMENT_ROM_END macros
  • I also had to make a SEGMENT_ROM_START_OFFSET macro because some places in the codebase do arithmetic with a u8* pointer and doesn't like the address to be casted to uintptr_t before the arithmetic. Same reason for SEGMENT_ROM_SIZE2.

@engineer124 engineer124 mentioned this pull request Jun 5, 2023
Copy link
Contributor

@EllipticEllipsis EllipticEllipsis left a 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
Copy link
Contributor

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?

Copy link
Collaborator Author

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

Copy link
Contributor

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.

Copy link
Collaborator Author

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

Makefile Show resolved Hide resolved
include/variables.h Outdated Show resolved Hide resolved
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);
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Contributor

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.

Copy link
Collaborator Author

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? 🤷‍♂️

Copy link
Contributor

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.

src/boot_O2_g3/idle.c Outdated Show resolved Hide resolved
@@ -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);
Copy link
Contributor

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.

Copy link
Collaborator

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?

src/code/TwoHeadArena.c Outdated Show resolved Hide resolved
@@ -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);
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Contributor

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.

Copy link
Collaborator Author

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;
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Contributor

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);
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Collaborator

@hensldm hensldm left a 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.

include/z64.h Outdated Show resolved Hide resolved
src/overlays/actors/ovl_En_Fish2/z_en_fish2.c Outdated Show resolved Hide resolved
AngheloAlf and others added 2 commits July 4, 2023 09:48
@hensldm hensldm mentioned this pull request Jul 8, 2023
@engineer124 engineer124 removed the Needs-second-approval Second approval label Aug 15, 2023
Copy link
Collaborator

@tom-overton tom-overton left a 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.

@tom-overton tom-overton added Merge-ready All reviewers satisfied, just waiting for CI and removed Needs-first-approval First approval labels Oct 31, 2023
if ((objectSlot > OBJECT_SLOT_NONE) && (Object_IsLoaded(&play->objectCtx, objectSlot))) {
void* segBackup = gSegments[6];
if ((objectSlot >= 0) && (Object_IsLoaded(&play->objectCtx, objectSlot))) {
Copy link
Collaborator

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

@engineer124 engineer124 merged commit f276d2b into zeldaret:main Nov 1, 2023
1 check passed
@AngheloAlf AngheloAlf deleted the int-conversion branch November 1, 2023 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Clean up Merge-ready All reviewers satisfied, just waiting for CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants