-
-
Notifications
You must be signed in to change notification settings - Fork 244
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
Assume C99 fixed sized ints exist, use them #470
Conversation
The standard seems to indicate that these are not required by a compiler, which is why our previous coding provided workarounds when they weren't available. It's possible that we'd like to require them for HDF5 to work correctly now, but I don't know if there's any situations where that might be a problem for any users. |
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.
Let's do the H5public.h changes in a separate PR so we can merge the internal changes to 1.12 and 1.10.
We directly use C99 types like uint64_t, uint32_t, etc. in many places in HDF5. If even Microsoft supports it, I think it's safe to assume it's ubiquitous. I'm definitely in favor of reducing our ifdef madness by eliminating obsolete cruft. |
In this case though, line 293 is always true, is it not? The whole chunk is dead code. |
We use it because we typedef it when it's not defined by the compiler. I do think it's OK to get rid of our backward compatibility shims at this point though. :-) |
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.
As long as this passes for all CI & nightly regression tests, should be good.
Yes, let’s do it!
Thank you, all!
On Mar 15, 2021, at 11:47 AM, Quincey Koziol ***@***.***> wrote:
We directly use C99 types like uint64_t, uint32_t, etc. in many places in HDF5. If even Microsoft supports it, I think it's safe to assume it's ubiquitous. I'm definitely in favor of reducing our ifdef madness by eliminating obsolete cruft.
We use it because we typedef it when it's not defined by the compiler.
I do think it's OK to get rid of our backward compatibility shims at this point though. :-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#470 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLFT3OVW5UJHLZ4QBRL5FTTDY23LANCNFSM4ZEI2GUQ>.
|
OK, I'll keep working on this PR then... |
27a2a6f
to
18d596a
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.
This define, H5_SIZEOF_LONG_DOUBLE, cannot be removed anywhere because not all platforms support long double. Windows insists that long double is just double and this define will be zero on that platform.
Really?! It's not 8, just like
And MS docs say |
It is 0 because the code it encloses would be used, in tools lib the else code of the same if define is used. |
I just double-checked that code and realized I might be wrong, the code in the ifdef block might be included and the "if type equals" fail the result will be the same that I see. |
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.
Need to check a windows build, to verify the define is not 0.
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.
Fortran-related changes look good.
Could you point me to the code to which you refer? |
tools/lib/h5tools_dump.c change. |
53cfd9b
to
13b12f2
Compare
This is failing a test in dtransform.c on Ubuntu with gcc 9.3.0, both before and after the latest commit: Testing contiguous, no data type conversion (ldouble->ldouble) It seems the calculated value for the first number in the array is "nan" instead of "2.22222". |
@lrknox why the new commit f4a044b? Is it to undo a799020? I separated a799020 as @derobins requested, and can drop that commit when this is no longer WIP. But I still don't see the need. When can |
@derobins H5public.h changes have been removed from this PR. |
@seanm Sorry, did not see this comment. I was preparing to merge this when @derobins was satisfied, but is your WIP indicating you aren't ready for merge? |
Correct. For one, there are apparently tests failing, which I have yet to look at. There are also other C99 types I intend to clean up. I really created this PR to have a place to discuss which kinds of changes y'all would or would not accept. |
f4a044b
to
ba227b0
Compare
c4d97ca
to
7593be1
Compare
e56bc83
to
6845ec9
Compare
b3d8d85
to
a4d387f
Compare
Note, this is only assuming that `long double` exists, no assumptions about its size have been touched. Didn't remove any code that does things like test if `long double` and `double` have different sizes.
23df5ae
to
8c1eea7
Compare
All checks passed after the clang-format change commit. See https://github.com/HDFGroup/hdf5/actions/runs/1382094984. |
* Committing clang-format changes * Assume C99 fixed sized ints exist, use them * Assume H5_SIZEOF_LONG_DOUBLE != 0, `long double` has existed since C89 Note, this is only assuming that `long double` exists, no assumptions about its size have been touched. Didn't remove any code that does things like test if `long double` and `double` have different sizes. * Committing clang-format changes Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Sean McBride <sean@rogue-research.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
No description provided.