> On Tue, Dec 19, 2017 at 1:04 AM, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > >> From: "Theo de Raadt" <dera...@openbsd.org> > >> Date: Mon, 18 Dec 2017 11:57:32 -0700 > >> > >> I think kernel should be fixed to return ENFILE in that case. > > > > Was thinking the same thing. > > > > On Tue, Dec 19, 2017 at 12:57 AM, Theo de Raadt <dera...@openbsd.org> wrote: > > I think kernel should be fixed to return ENFILE in that case. > > Yes, maybe. Besides, it is already described in the man page. But, but > would it be > correct from the point view of an error description? > > I mean, ENFILE is something related to fd(s) table and we may get it > during pipe()/pipe2() because of falloc() which follows pipespace(). But > here in pipespace() we don't touch fd table yet, and actually works with > memory. > > So, if you see ENFILE more suitable for this, I will send v2 with replaced > errno in pipespace() if no one does not mind.
You are missing a point. Should userland programmers have to check for a myriad of error conditions, which effectively result in the same conclusion and same coping strategy? Today ENFILE and EMFILE. Tomorrow ENOMEM. What next after that? The errno abstraction intentionally insists on less error numbers, so that userland code doesn't need to keep adapting. Adding new error conditions isn't sane. It is better to map a condition to another condition which already exists, and try to map it to something similar. In this case, ENOMEM is potentially transient and temporary like ENFILE. Both are system-side temporary impact.
