On 11/09/2019 11.37, Uwe Kleine-König wrote:
> On 9/11/19 8:43 AM, Rasmus Villemoes wrote:
>> On 11/09/2019 02.15, Joe Perches wrote:
>>> On Tue, 2019-09-10 at 18:26 +0300, Andy Shevchenko wrote:
>>>> On Mon, Sep 9, 2019 at 11:39 PM Rasmus Villemoes
>>>> <linux@xxxxxxxxxxxxxxxxxx> wrote:
>>>>> +{
>>>>> + /* Might as well accept both -EIO and EIO. */
>>>>> + if (err < 0)
>>>>> + err = -err;
>>>>> + if (err <= 0) /* INT_MIN or 0 */
>>>>> + return NULL;
>>>>> + if (err < ARRAY_SIZE(codes_0))
>>>>> + return codes_0[err];
>>>>
>>>> It won't work if one of the #ifdef:s in the array fails.
>>>> Would it?
>>
>> I don't understand what you mean. How can an ifdef fail(?), and what
>> exactly won't work?
>
> I think Joe means: What happens if codes_0[57] is "" because there is no
> ESOMETHING with value 57.
[That was Andy, not Joe, I was lazy and replied to both in one email
since Joe quoted all of Andy's questions].
So first, for good measure, codes_0[57] may be NULL but not "". Second,
if we're passed 57 but no Exxx on this architecture has the value 57,
then yes, we return NULL, just as if we're passed -18 or 0 or 1234. But
57 (or -57, or ERR_PTR(-57)) would realistically never find its way into
an err variable (be it pointer or integer) in the first place when no
ESOMETHING has the value 57.
Except for the case where somebody in the future adds #define ESOMETHING
57 to their asm/errno.h and starts using ESOMETHING, without updating
the table in errcode.c. But if that's the case, letting the caller
handle the "sorry, I can't translate 57 to some string" is still the
right thing to do.
Rasmus
