Avoid hardcoded assumed pointer types #384
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Depends on blas-lapack-rs/lapack-sys#15 This replaces hardcoded platform-specific `char*` types with the opaque types from [`core::ffi`](https://doc.rust-lang.org/stable/core/ffi/type.c_char.html). This is necessary when cross-compiling. I believe when interacting with C and Fortran, both `lax` and `lapack-sys` should not assume integer and pointer types. Current setup is biased towards x86_64 platform and it could cause broken builds and undefined behavior on other platforms. For example, cross compilation build could fail with: error[E0308]: mismatched types --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lax-0.16.0/src/cholesky.rs:30:26 | 30 | $trf(uplo.as_ptr(), &n, AsPtr::as_mut_ptr(a), &n, &mut info); | ---- ^^^^^^^^^^^^^ expected `*const u8`, found `*const i8` | | | arguments to this function are incorrect ... 41 | impl_cholesky_!(c64, lapack_sys::zpotrf_); | ----------------------------------------- in this macro invocation | = note: expected raw pointer `*const u8` found raw pointer `*const i8` note: function defined here --> /workdir/.build/docker-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/release/build/lapack-sys-5fad11066d38a1a6/out/bindings.rs:12886:12 Full build log for aarch64-unknown-linux-gnu: [build.log.txt](https://github.com/user-attachments/files/17706011/build.log.txt) In this PR I change `i8` to `core::ffi::c_char` - this, for example, resolves to `i8` on x86 and to `u8` on ARM, but is also universal for any platform rust supports, removing bias towards x86.
| Closing as duplicate to #354 |
| Reopening, because my version is better - it uses Either way the root cause is blas-lapack-rs/lapack-sys#15 and it needs to be merged for the thing to not be UB. |
| #354 now also uses |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Depends on blas-lapack-rs/lapack-sys#15
This replaces hardcoded platform-specific
char*types with the opaque types fromcore::ffi. This is necessary when cross-compiling.I believe when interacting with C and Fortran, both
laxandlapack-sysshould not assume integer and pointer types. Current setup is biased towards x86_64 platform, for the most part due to a bug inlapack-sys(see blas-lapack-rs/lapack-sys#15), and it could cause broken builds and undefined behavior on other platforms.For example, cross compilation build could fail with:
Full build log for aarch64-unknown-linux-gnu:
build.log.txt
In this PR I change
i8tocore::ffi::c_char- this, for example, resolves toi8on x86 and tou8on ARM, but is also universal for any platform rust supports, removing bias towards x86.