Re: [Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Fri, 2016-07-22 at 15:57 +0200, Hannes Reinecke wrote:
> 
> > I guess that almost all functions return only a few possible error codes?
> 
> Precisely. If we had a way of specifying "the return value is an errno
> with the possible values '0', '-EIO', and '-EINVAL'" that would be
> _so_ cool.

And perpetually out of date. Because functions call through to *other*
functions which might return an errno outside the 'known' set.

Any why would you *want* to know the precise set of errnos that a
function might return, if not to deliberately code your error handling
non-defensively?

I can understand wanting to distinguish between errors and non-errors
and ensure that the ranges cannot overlap. But IS_ERR_VALUE() typically
reserves the whole range to -4095 (-MAX_ERRNO) for that. And I don't
think we'd ever want to do anything different.

In particular I don't want anyone ever saying "oh, -123 is a valid non-
error return but no other negative numbers are. But that's OK because
it'll never *actually* return an error of -ENOMEDIUM so there's no
ambiguity."

Of course, that's a silly example... but it's precisely where it sounds
like you're going, from the above citation :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]