Suricata

By the errno approach are you referring to a more limited set of error codes? Or something functional like a thread local error variable as well?

Was thinking about a limited set of codes (EINVAL, ENOMEM, ENOENT, etc). But it would be good to consider how these errors would be passed along too.

Have been thinking about this one recently, so some points of discussion.

Do you have find that having the error code in the log message is very useful at all? I don't find it that useful, and its not something you see in most modern software systems (outside stuff like Microsoft, or Cisco where they do have a unique code for each error across the entire system). The other thing to consider is that SCLogWarn requires a code, where I don't think it always makes sense to have one.

But a set of error codes does make sense for passing things around to keep some context. This way we can avoid logging where the error occurred, and pass back an error code (would return values < 0 work for this)? In Rust it is idiomatic to use an enum of possible failures with the result type, so we could have a pretty close usage pattern.

I'd also like to suggest forgetting about the stability of the error code number? Does anything depend on this? It would be very nice if we could have our set of codes alphabetized, and not worry about their action value (or in Rust, where idiomatically they wouldn't have an integer value - but we can give them one).

Jason Ish wrote in #note-3:

I'd also like to suggest forgetting about the stability of the error code number? Does anything depend on this? It would be very nice if we could have our set of codes alphabetized, and not worry about their action value (or in Rust, where idiomatically they wouldn't have an integer value - but we can give them one).

Or drop the error code from log messages.