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

LAGraph: Use compile-time checks for size of uintptr_t #470

Merged
merged 1 commit into from
Oct 26, 2023

Conversation

mmuetzel
Copy link
Contributor

Instead of checking the size of uintptr_t on run-time (repeatedly inside a loop), move that check to the preprocessor. That way code that will never be executed isn't compiled.

Modern compilers might be able to optimize the checks and code paths away that will never be executed. But there is no guarantees they will do that.

I hope it is ok to check at compile time if the pointer size is neither 32-bit nor 64-bit. (Compilation will likely fail at other points anyway if that should be the case.)

Instead of checking the size of `uintptr_t` on run-time (inside a loop),
move that check to the preprocessor. That way code that will never be
executed isn't compiled.

Modern compilers might be able to optimize the checks and code paths
away that will never be executed, there is no guarantees they will do
that.

I hope it is ok to check at compile time if the pointer size is neither
32-bit nor 64-bit. (Compilation will likely fail at other points anyway
if that should be the case.)
@DrTimothyAldenDavis
Copy link
Owner

Yes, that looks like a good idea. Yes, if the code fails to compile because UINTPTR_MAX or uintptr_t doesn't exist, then that's OK. I doubt there are any compilers out there that support ANSI C11 but not those symbols.

@DrTimothyAldenDavis DrTimothyAldenDavis merged commit 177aada into DrTimothyAldenDavis:dev2 Oct 26, 2023
17 checks passed
@mmuetzel
Copy link
Contributor Author

I don't think there are any C99 compatible compilers for which UINTPTR_MAX or uintptr_t don't exist.
But there might be exotic platforms out there for which neither 32-bit nor 64-bit integers are native types. For those, the standard would require that neither uint32_t nor uint64_t are valid types. (I believe there where some historic platforms which used 24-bit integer math.)
But for those platforms, SuiteSparse wouldn't compile for multiple different reasons anyway...

@mmuetzel
Copy link
Contributor Author

Re-reading your comment, I'm not sure what you mean by "ANSI C11". There is "ANSI C" (sometimes also referred to as "C89"). And there is "C11".
ANSI C has none of the new integer types. But C11 always has uintptr_t (it's mandatory since C99).
Afaict, most (if not all) projects in SuiteSparse require at least C11. I don't know if any would compile with ANSI C. (Probably not.)

@DrTimothyAldenDavis
Copy link
Owner

By "ANSI C11", I mean C11 I guess (ISO/IEC 989:2011), https://en.wikipedia.org/wiki/C11_(C_standard_revision) .

I guess the term "ANSI C" is only https://en.wikipedia.org/wiki/ANSI_C , and does not include C11. I thought C11 was "ANSI C11" but I that's not correct, I see now.

Anyway, I do require at least C11.

The document I have on C11 states that uintptr_t is optional, but it also says the same thing for uint32_t and uint64_t. I require the latter two, of course. I didn't realize they were optional (yikes!).

So it does seem perfectly safe to assume I have all of uintptr_t, uint32_t, uint64_t, etc.

image

image

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