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
Signal hook uses the low-level c_int to represent signal numbers, because signal numbers are somehow "open" enum ‒ it's not clear what signals might be available on whatever platform someone compiles signal-hook on, or if they are having a custom kernel patch for their embedded device.
But if one wants to present the signal to the user (maybe in the logs, or something), printing the number is not the most user-friendly thing one can do. It would be nice if:
We had some way to convert that to user-friendly name (either having an enum with TryFrom<c_int> on it, or some kind of fn(c_int) -> &str function)
Debug outputs of various things (especially the Origin) would do this conversion.
❓ If we decide to go with that enum type, should our API generally accept that in addition to raw c_int, in the form of Into<c_int>, or the like?
The text was updated successfully, but these errors were encountered:
Signal hook uses the low-level
c_int
to represent signal numbers, because signal numbers are somehow "open" enum ‒ it's not clear what signals might be available on whatever platform someone compiles signal-hook on, or if they are having a custom kernel patch for their embedded device.But if one wants to present the signal to the user (maybe in the logs, or something), printing the number is not the most user-friendly thing one can do. It would be nice if:
TryFrom<c_int>
on it, or some kind offn(c_int) -> &str
function)❓ If we decide to go with that enum type, should our API generally accept that in addition to raw
c_int
, in the form ofInto<c_int>
, or the like?The text was updated successfully, but these errors were encountered: