Peter Maydell <peter.mayd...@linaro.org> writes: > On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy > <vsement...@virtuozzo.com> wrote: >> Somehow, in general, especially with long function names and long parameter >> lists I prefer >> >> ret = func(..); >> if (ret < 0) { >> return ret; >> } > > Personally I prefer the other approach -- this one has an extra line > in the source and > needs an extra local variable.
Me too, except when func(...) is so long that if (func(...) < 0) { becomes illegible like if (func(... yadda, yadda, yadda, ...) < 0) { Then an extra variable can improve things. >> Are you sure that adding a lot of boolean functions is a good idea? I >> somehow feel better with more usual int functions with -errno on failure. >> >> Bool is a good return value for functions which are boolean by nature: >> checks, is something correspond to some criteria. But for reporting an error >> I'd prefer -errno. > > When would we want to return an errno? I thought the whole point of the > Error* was that that was where information about the error was returned. > If all your callsites are just going to do "if (ret < 0) { ... } then having > the functions pick an errno value to return is just extra work. 0/-1 vs. true/false is a matter of convention. Lacking convention, it's a matter of taste. 0/-1 vs. 0/-errno depends on the function and its callers. When -errno enables callers to distinguish failures in a sane and simple way, use it. When -errno feels "natural", I'd say feel free to use it even when all existing callers only check < 0. When you return non-null/null or true/false on success/error, neglecting to document that in a function contract can perhaps be tolerated; you're using the return type the common, obvious way. But when you return 0/-1 or 0/-errno, please spell it out. I've seen too many "Operation not permitted" that were actually -1 mistaken for -EPERM. Also too many functions that return -1 for some failures and -errno for others.