Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > > Another thing that keeps bugging me about prepend_path() is the > set of return values. I mean, 0/1/2/3/-ENAMETOOLONG, and all > except 0 are unlikely? Might as well make that 0/1/2/3/-1, if > not an outright 0/1/2/3/4. And prepend() could return bool, while > we are at it (true - success, false - overflow)... I remember seeing that the different callers of prepend_path treated those different cases differently. But now that I look again the return value 3 (escaped) gets lumped together with 2(detached). On second look it appears that the two patterns that we actually have are basically: char *__d_path(const struct path *path, const struct path *root, char *buf, int buflen) { error = prepend_path(path, root, &res, &buflen); if (error < 0) return ERR_PTR(error); if (error > 0) return NULL; return res; } char *d_absolute_path(const struct path *path, char *buf, int buflen) { error = prepend_path(path, &root, &res, &buflen); if (error > 1) error = -EINVAL; if (error < 0) return ERR_PTR(error); return res; } With d_absolute_path deciding that return value 1 absolute is not an error. That does look like there is plenty of room to refactor and make things clearer. Eric