Mike Belopuhov wrote: > On 27 February 2016 at 08:21, Michael McConville <mm...@mykolab.com> wrote: > > Michael McConville wrote: > >> Michael McConville wrote: > >> > Does this make sense? > >> > >> I just realized that the allocation failure checks earlier in the > >> function return ENOBUFS. This probably makes more sense for the sake of > >> consistency. > > > > The best I can tell, the only use of this function is in > > sys/crypto/crypto.c:157. It's accessed through a pointer stored in a > > struct by crypto_register(). That usage doesn't seem to be affected > > by the below change, considering that the outcome would be no > > different than that of the other ENOBUFS failures above it. > > > > So why change it to ENOMEM then? Nothing there returns it. > I think this is just needless churn.
I was proposing to change it from EINVAL to ENOBUFS. I don't think it's churn. The current returned error code seems objectively wrong to me, and all other allocation failures in this function return ENOBUFS. deraadt supported it but asked me to ensure that it wouldn't affect downstream error handling.
