-
Notifications
You must be signed in to change notification settings - Fork 29
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
Fixes to various clang warnings, increased minimum CMake version #126
Conversation
Swapped the two halves of the && check. Safer to check the index first, before accessing the buffer. Out of range access was probably possible the old way.
Several declarations and definitions didn't quite match.
This was an antique K&R style function declaration.
Just marked private functions as static.
… corresponding header
Unlike C++, the void is required here in C, strictly speaking.
These were unused.
Many of these header have been standardized since C89, others have been obsolete forever. This started as fixing some -Wundef warnings, but then I thought I'd clean up more.
Indeed this was an infinite recursion. Looking at the functions above, and following that pattern, I think this meant to call the variant without the `2`.
These variables were indeed unused, the sting not appearing elsewhere in the file.
PrintVersion() called exit() meaning it never returned. There is only caller of PrintVersion(), so just moved the exit() call from inside to outside the function.
The prototype in the header was already in an #if 0.
Fixes warning "Compatibility with CMake < 3.10 will be removed from a future version of CMake." from CMake 3.31 Also moved it higher to fix "cmake_minimum_required() should be called prior to this top-level project() call" warning.
@vfonov apologies for so many commits, but each is small. I thought it best to do 1 comment per warning flag. Please review carefully. I'm no expert in this codebase! |
Looks good to me. @seanm does this all pass An expanded testing swapping this patched version in the minc-toolkit-v2 superbuild tests would also be welcome. |
No, but neither does it before this PR. For me, the same tests fail before and after. |
Is this the case for everyone? |
|
Running one of the tests has a lot of HDF5 messages, I wonder if this isn't a linux vs macOS difference, but rather a due to different HDF5 versions. What version are you using? I'm using from git master. |
I just tried on |
OK I'll try the same version... |
Is it maybe just that I'm supposed to have a |
No The errors look like your HDF5 is installed in |
So, I merged most of the commits into develop. The only one that is problematic is 9849b33 - those checks still needed on Linux, in particular because there is a difference between Apple and Linux there. |
Then this PR should be formally closed? |
probably, if we ignore one unaccepted commit. |
Ah, so this might be because configuring HDF5 was not finding my zlib, so I built without zlib support. HDF5 has a variable
Do you recall which?
Sure, we can close this now. |
I cannot close this. Either PR author or someone with write permission here needs to do it. |
Created: HDFGroup/hdf5#5155 |
|
No description provided.