On Mon, Feb 13 2023, Max Gurtovoy <[email protected]> wrote: > On 13/02/2023 10:16, Michael S. Tsirkin wrote: >> On Mon, Feb 13, 2023 at 02:54:47AM +0200, Max Gurtovoy wrote: >>>> For some system calls and library functions (e.g., >>>> getpriority(2)), -1 is a valid return on success. In such cases, >>>> a successful return can be distinguished from an error return by >>>> setting errno to zero before the call, and then, if the call >>>> returns a status that indicates that an error may have occurred, >>>> checking to see if errno has a nonzero value. >>>> >>>> >>>> >>>>> Description is already good enough to describe what they are. >>>>> Can we please drop Linux wording? >>>> >>>> But why should we? It's where 22 comes from so this way people are not >>>> wondering about the value, and it's somewhat helpful for Linux >>>> developers. >>>> >>> >>> I also think we should not mention Linux. I don't think it's mentioned >>> currently in the spec and no good reason to do so now. >> >> But we do: fuse, input at least both do. >> >>> Also value of 22 is not mandatory for this EINVAL status code. It can be >>> just 1 (the first number after the OK status). >> >> 22 makes it a tiny bit easier for kvm. So why not. > > Because people comment on that in the review :) and because a > specification should be OS independent. > 22 might be EINVAL in Linux but a success in MyOS is my lucky number is 22. > > not a big issue for me, but I prefer to have a cleaner spec than maybe > simplify something in a very specific OS.
Well, my take is: - we have to pick *something* - using EINVAL == 22 is very convenient for one of the most common (the most common?) implementors - noting that we're trying to follow what Linux uses makes it clear what to pick for any new return codes --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
