Making EPERM friendlier

Posted Jan 22, 2013 11:51 UTC (Tue) by vonbrand (subscriber, #4458)
Parent article: Making EPERM friendlier

If errno is an integer, why not just use the full range? I.e., low 8 bits contain "traditional" errno, high 24 bits (uint32_t should be plenty... famous last words) contain details for whoever is groping for them. Frob perror(3) to use the full range on some feature macro, i.e., LINUX_VERSION >= 0x030900. Or am I missing something critical here?

Making EPERM friendlier

Posted Jan 23, 2013 1:57 UTC (Wed) by gdt (subscriber, #6284) [Link]

The critical thing you are missing is that a single error code is part of the problem.

What an application wants to know is: what happened, what should I tell the user, and what should I do next?

Take what to do next: Does it matter? Should you loop around and retry? Should you back up to the file selection interface and retry? Should you terminate cleanly (ie, telling the user WTF just happened, at the cost of more resources)? Is it so severe you should throw up your hands and exit uncleanly to give the system the best chance to bounce back?

If you go an add a bazillion more integer values then the "what to do next" problem becomes a bazillion times harder. One thing which a redesign should do is to stop the overloading of errno with meaning.