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

[Julia Lawall <julia.lawall@lip6.fr>]

On Tue, 26 Jul 2016, David Woodhouse wrote:

> 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.

If you have a script to calculate it, it doesn't have to be perpetually
out of date.  The problem is just the time to collect the information for
the whole kernel.  It could be a good intern project.

julia

>
> 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