Hi Eric, > > since the caller does not know > > in advance how long the string will be (i.e. how long the buffer needs > > to be for a complete message), that ERANGE should be the "lowest priority" > > error. That is, I think EINVAL should take precedence over ERANGE. > > I personally disagree - if I call strerror_r(-12, buf, 17) and get > ERANGE, then I immediately know that "Unknown error -1" is suspect; but > if I get EINVAL, then I've just printed a misleading error number, and > the only way to tell if I didn't suffer from truncation is to retry with > a larger buffer until I get an answer with a strlen() smaller than my > buffer. That is, if I am going to _guarantee_ that all errors produce a > non-empty message, I'd much rather prefer learning that my buffer was > too small until I got my complete non-empty message.
That's a valid scenario. The scenario I was thinking of is someone who wants to know whether an errno value is valid. This is a special case of functions that return multiple pieces of information, and one of them is a string. If ERANGE takes precedence, the caller needs to provides a large enough buffer for the string even if he's not interested in the string but only in the other pieces of information. So, strerror_r (errnum, buf, 10) == EINVAL will no longer be a way to test whether errnum is valid. But I agree that if ERANGE takes precedence, it makes it easier to write reliable programs, and it is not a blocker issue for the scenario I imagined. Bruno -- In memoriam Alfred Grünberg <http://en.wikipedia.org/wiki/Alfred_Grünberg>
