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

Assume C99 fixed sized ints exist, use them #470

Merged
merged 6 commits into from
Nov 8, 2021

Conversation

seanm
Copy link
Contributor

@seanm seanm commented Mar 13, 2021

No description provided.

@seanm
Copy link
Contributor Author

seanm commented Mar 13, 2021

@qkoziol @derobins is this an acceptable direction? I can do the same for 8, 16, and 64.

@qkoziol
Copy link
Contributor

qkoziol commented Mar 13, 2021

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.

Copy link
Member

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

@derobins
Copy link
Member

derobins commented Mar 14, 2021

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.

@seanm
Copy link
Contributor Author

seanm commented Mar 14, 2021

Let's do the H5public.h changes in a separate PR so we can merge the internal changes to 1.12 and 1.10.

In this case though, line 293 is always true, is it not? The whole chunk is dead code.

@qkoziol
Copy link
Contributor

qkoziol commented Mar 15, 2021

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. :-)

Copy link
Contributor

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

@epourmal
Copy link

epourmal commented Mar 15, 2021 via email

@seanm
Copy link
Contributor Author

seanm commented Mar 15, 2021

OK, I'll keep working on this PR then...

Copy link
Contributor

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

@seanm
Copy link
Contributor Author

seanm commented Mar 16, 2021

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...

long double has been in C since C89. That's not to say that it needs to be any bigger than double, just as long int is not necessarily any bigger than int.

and this define will be zero on that platform

Really?! It's not 8, just like H5_SIZEOF_DOUBLE? The comment above it says:

/* The size of `long double', as computed by sizeof. */
#cmakedefine H5_SIZEOF_LONG_DOUBLE @H5_SIZEOF_LONG_DOUBLE@

And MS docs say sizeof(long double) is 8.

@byrnHDF
Copy link
Contributor

byrnHDF commented Mar 17, 2021

Really?! It's not 8, just like H5_SIZEOF_DOUBLE? The comment above it

It is 0 because the code it encloses would be used, in tools lib the else code of the same if define is used.

@byrnHDF
Copy link
Contributor

byrnHDF commented Mar 17, 2021

Really?! It's not 8, just like H5_SIZEOF_DOUBLE? The comment above it

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.

Copy link
Contributor

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

@byrnHDF byrnHDF self-requested a review March 17, 2021 13:00
Copy link
Contributor

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

@seanm
Copy link
Contributor Author

seanm commented Mar 17, 2021

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.

Could you point me to the code to which you refer?

@byrnHDF
Copy link
Contributor

byrnHDF commented Mar 17, 2021

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.

Could you point me to the code to which you refer?

tools/lib/h5tools_dump.c change.

src/H5Ztrans.c Outdated Show resolved Hide resolved
src/H5Ztrans.c Outdated Show resolved Hide resolved
@lrknox
Copy link
Collaborator

lrknox commented Mar 19, 2021

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".

@seanm
Copy link
Contributor Author

seanm commented Mar 22, 2021

@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 #if H5_SIZEOF_INT64_T >= 8 be false? You realize all that code only does anything in such dead branches, right?

@lrknox
Copy link
Collaborator

lrknox commented Mar 22, 2021

Let's do the H5public.h changes in a separate PR so we can merge the internal changes to 1.12 and 1.10.

@derobins H5public.h changes have been removed from this PR.

@lrknox
Copy link
Collaborator

lrknox commented Mar 22, 2021

@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 #if H5_SIZEOF_INT64_T >= 8 be false? You realize all that code only does anything in such dead branches, right?

@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?

@seanm
Copy link
Contributor Author

seanm commented Mar 22, 2021

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.

@byrnHDF byrnHDF added the WIP Work in progress (please also convert PRs to draft PRs) label May 6, 2021
@seanm seanm changed the title WIP: Assume C99 fixed sized ints exist, use them Assume C99 fixed sized ints exist, use them Aug 12, 2021
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.
@seanm
Copy link
Contributor Author

seanm commented Oct 25, 2021

@qkoziol @derobins @lrknox @byrnHDF @epourmal OK, I found what was making tests fail. I think this is ready now.

@lrknox
Copy link
Collaborator

lrknox commented Oct 26, 2021

All checks passed after the clang-format change commit. See https://github.com/HDFGroup/hdf5/actions/runs/1382094984.

@lrknox lrknox merged commit 9cea7c9 into HDFGroup:develop Nov 8, 2021
lrknox added a commit that referenced this pull request Apr 1, 2022
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WIP Work in progress (please also convert PRs to draft PRs)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants