-
-
Notifications
You must be signed in to change notification settings - Fork 291
Refactor warning macros #5432
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
Refactor warning macros #5432
Conversation
Replaces the scheme in H5warnings.h with a more compiler-agnostic one that relocates ifdef complexity to the warnings header file and uses better naming.
* Add cast alignment warnings for C++ tests * Fix the nonstandard suffix warnings * Update .clang-format * Remove the C99 extensions warning
Java is broken in CMake, so I can't debug this
…nto warning_refactor
Until whatever CMake + Java is doing is fixed
This would be ready to review if Java worked on Ubuntu, which it does not. Without a working Java setup, I can't debug the Java JNI header issue, where it appears to have a problem seeing H5warnings.h via H5private.h. I'd also like to extend this to MSVC warnings, but I can't get HDF5 to compile with Visual Studio due to complex number errors. It's unclear why HDF5 builds in CI but not locally with Visual Studio. |
@byrnHDF or I might be able to take a look at java. What issue are you having with Java on Ubuntu?
Could you create an issue with the problems you're seeing? I might be able to take a look if I can get Visual Studio working somewhere. |
@@ -219,7 +217,6 @@ aux_assign_obj(const char *name, /* object name from traverse list */ | |||
} | |||
} | |||
|
|||
*obj = tmp; |
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.
Not a good idea to return a stack object through a pointer...
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.
This isn't returning a stack object, this is using struct assignment from tmp
to the struct pointed to by obj
, so it's perfectly fine. Plus it's a lot cleaner than the new solution if errors were to occur because all the fields were previously assigned all at once at the end here only on success, whereas the new solution could half-initialize the pointed to structure.
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.
Yeah, I tend to agree
This is ready for review now. FWIW, if we can fix a few stragglers in C++, Fortran, clang, and MSVC, we can start building with -Werror always and get rid of the special jobs. |
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.
Using snprintf eliminates the warning?
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.
Seconding this; is the warning just no longer issued?
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.
No longer complains (if it did, the -Werror checks would fail)
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'm not sure that we're currently building parallel with -Werror or at least that it works correctly. Some of the parallel builds use the HDF5_ENABLE_WARNINGS_AS_ERRORS option, but I can see this warning in https://github.com/HDFGroup/hdf5/actions/runs/14818490824/job/41602216637, for example.
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 think the option may simply not be covering all the cases we're interested in turning into an error from a warning. Looks like this particular warning may need to be suppressed again. We'll check into the issues with the option outside of this PR.
#define H5_DIAG_OFF(x) H5_DIAG_PRAGMA(push) H5_DIAG_PRAGMA(ignored H5_DIAG_JOINSTR("-W", x)) | ||
#define H5_DIAG_ON(x) H5_DIAG_PRAGMA(pop) | ||
#if defined(__clang__) || defined(__GNUC__) | ||
#define H5_WARN_CAST_ALIGNMENT_OFF H5_WARN_OFF("cast-align") |
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.
Out of all the warning types, cast-align
is one that I think we should never allow suppressing warnings for. While it's fine on some platforms it's certainly not on others and will likely lead to subtle issues.
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.
Looks good to me, modulo the possible revert on the pack option (but I don't have a strong opinion either way on that)
@@ -98,7 +98,9 @@ test_compound_2() | |||
bkg = static_cast<unsigned char *>(malloc(nelmts * sizeof(dst_typ_t))); | |||
orig = static_cast<unsigned char *>(malloc(nelmts * sizeof(src_typ_t))); | |||
for (i = 0; i < nelmts; i++) { | |||
s_ptr = (reinterpret_cast<src_typ_t *>(orig)) + i; | |||
H5_WARN_CAST_ALIGNMENT_OFF | |||
s_ptr = (reinterpret_cast<src_typ_t *>(orig)) + i; |
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.
If these few places are the only locations where cast-align
is currently suppressed, I'd much rather these be fixed (maybe in a separate PR) than continuing to be suppressed. The solution is very simple so no real need to keep suppressing cast-align
.
Great changes that I'd like to see merged to fix the new annoying warnings from C23-related issues; just a couple minor things. |
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'll look into the remaining issue with the new warning later on; I'd much rather have the warning suppression reworking in.
Fixes #5424