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

Fix Warnings #170

Merged

Conversation

insertinterestingnamehere
Copy link
Collaborator

No description provided.

@insertinterestingnamehere
Copy link
Collaborator Author

Okay, this one's ready to go. It resolves all warnings enabled in the "picky" build except for those involved in #173. Once that's resolved too we can enable -Werror to avoid regressions here. I haven't looked at anything from -Wextra yet.

@insertinterestingnamehere
Copy link
Collaborator Author

Worth noting: this doesn't fix all the warnings in the config scripts since a lot of those warnings are inherited from stuff happening upstream with autotools. I just fixed the warnings internal to the configure scripts that have obvious fixes and come from files in qthreads that aren't vendored in from somewhere else.

Some of the warnings are either inherited from autotoools,
inherited from files vendored from upstream, or unavoidable
given the nature of the test. This takes care of warnings
that don't fall into those categories though.
Copy link
Collaborator

@janciesko janciesko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding replacing the INTERNAL macro - is the function attribute not valid for all compilers? If we would like to restrict the visibility to hidden for dynamic linkage via static, we might consider changing the macro implementation instead.


snprintf(dflt_str, 10, "%lu", dflt);
snprintf(dflt_str, 21, "%lu", dflt);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 21?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The max length of an unsigned long is 20 digits. snprintf needs one more character than the max size, so 21.

@@ -71,7 +65,7 @@ void INTERNAL qt_makectxt(uctxt_t *ucp,
/* HOWEVER, the function may not be expecting to pull from the stack,
* several 64-bit architectures expect that args will be in the correct
* registers! */
ucp->mc.mc_edi = va_arg(argp, uintptr_t);
ucp->mc.mc_edi = *(uintptr_t*)sp;
Copy link
Collaborator

@janciesko janciesko Nov 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes more sense to me. Thanks for cleaning it up!

@insertinterestingnamehere
Copy link
Collaborator Author

Regarding replacing the INTERNAL macro - is the function attribute not valid for all compilers? If we would like to restrict the visibility to hidden for dynamic linkage via static, we might consider changing the macro implementation instead.

I'm not actually changing the INTERNAL macro here. What I did do is move some functions that were declared as INTERNAL to being static instead since they weren't used anywhere else. In a lot of the cases this was the simplest way to clear up the missing prototypes warnings.

@insertinterestingnamehere
Copy link
Collaborator Author

To clarify a bit more: there are a few places the INTERNAL macro is still needed and used. I don't see the need to change it. It's what's needed for specifying functions that we want to be internal to our .so but that need to be linked across translation units. The functions I changed to static aren't used across translation units though so making them static made more sense to get rid of the function prototype warnings (as opposed to doing some kind of forward declaration that allows them to be used elsewhere).

@janciesko
Copy link
Collaborator

Ok, thanks, in that case, would it make sense to add a new macro, maybe FUNCTION_IS_UNUSED that expands to the static qualifier and using that in those functions?

@insertinterestingnamehere
Copy link
Collaborator Author

I think static really is the correct thing here. These functions are used, but only within their translation unit. If they were completely unused I'd just remove them entirely. In theory we could do a macro for translation-unit local linkage, but the extra layer of indirection doesn't really give us anything in this case. Across C implementations that's consistently what static does for functions anyway.

@janciesko
Copy link
Collaborator

Agreed

Copy link
Collaborator

@janciesko janciesko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@insertinterestingnamehere
Copy link
Collaborator Author

Thank you!

@insertinterestingnamehere insertinterestingnamehere merged commit d6ce514 into sandialabs:main Nov 30, 2023
128 of 297 checks passed
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.

2 participants