You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The f! macro is used to reimplement C macros and inline functions in libc. It eagerly marks these functions as unsafe and extern. However, most of them don't actually need to be unsafe, and none of them need to be extern. Shall I update the f! macro to eliminate the extern and make the unsafe optional? This would be a backwards-compatible change, though it might generate "unnecessary unsafe" warnings in consumer code.
Here's an example of an f! function that plainly doesn't need to be unsafe:
pubfnWEXITSTATUS(status:::c_int) -> ::c_int{
status >> 8}
The text was updated successfully, but these errors were encountered:
I would personally prefer it stays as-is because platforms are often in disagreement about what's a macro, what's an inlined function, and what's an actual symbol. It's not really the place of libc to provide nice to use abstractions and/or make design decisions. The point of this crate is to be as simple as possible to append to.
The
f!
macro is used to reimplement C macros and inline functions in libc. It eagerly marks these functions asunsafe
andextern
. However, most of them don't actually need to beunsafe
, and none of them need to beextern
. Shall I update thef!
macro to eliminate theextern
and make theunsafe
optional? This would be a backwards-compatible change, though it might generate "unnecessary unsafe" warnings in consumer code.Here's an example of an
f!
function that plainly doesn't need to beunsafe
:The text was updated successfully, but these errors were encountered: