Theo de Raadt <[email protected]> wrote:
|> Ted Unangst <[email protected]> wrote:
|>|On Tue, Jan 14, 2014 at 15:08, Steffen Nurpmeso wrote:
|>|> Description:
|>|> The *c() family, which exists in FreeBSD and derivatives, is
|>|> helpful whenever something has to be done in the error case
|>|> (like necessary cleanup), while still being able to inform the
|>|> user about the original error that caused the problem.
|>|
|>|The motivation for this isn't clear.
|>|
|>| if (failure()) {
|>| saved_errno = errno;
|>| cleanup();
|>| errc(1, saved_errno, "fail");
|>|}
|>|
|>|vs
|>|
|>| if (failure()) {
|>| saved_errno = errno;
|>| cleanup();
|>| errno = saved_errno;
|>| err(1, "fail");
|>|}
|>|
|>|That's it, right? ok, I see the point, so maybe I should have said the
|>|motivation isn't compelling. It doesn't save that much work and leads
|>|to API explosion.
|>|
|>|If it could magically eliminate the need to save errno entirely,
|>|that'd be aswesome, but just knowing you need to save errno is
|>|literally 90% of the problem and this doesn't solve that.
|>
|> Ok, but under the surface errno is more than just assignment to
|> simple storage. It may not be that terrible with TLS, or on
|> platforms where accessing thread_self() is simply looking at
|> a register and TSD errno is treated special, but personally the
|> latter makes me sick :).
|
|It makes you sick? I'm sorry, but that stuff is carefully designed
|to even work in signal handlers, while the stuff you are talking about
|is not.
ye-ah, even there, but still there is a difference in between
restoring back to errno or having a simple movl+pushl or even only
the latter to prepare a new call stack (on x86). Not that anyone
cares about a few bytes here and there.
|> I think it is worth adding this interface, given how frequently
|> this family is used:
|>
|> $ git grep -E '(err|warn)\(' origin/master|wc -l
|> 19583
|>
|> all in all, including perl(1) stuff. A family that is used so
|> often can well tolerate a few more options, i think.
|> Just my one cent.
|
|The origian ones are used lot. That is very seperate from your
|argument that we need even more variants, which are not used now?
|It's horse shit. You just failed to justify it entirely.
On FreeBSD, as of end of December 2013:
$ git grep -E '(err|warn)\(' origin/master|wc -l
20614
$ git grep -E '(errc|warnc)\(' origin/master|wc -l
437
But i guess the situation would be a different one if the *c()
family would be available right from the start.
Nonetheless, wait another ten years, await a Raspberry-Tiny, maybe
the relation will change on FreeBSD, where there is an option.
|If your recommendation came with evidence, such as a full-tree audit
|suggesting all the places it should be used, then you might have some
My opinion would still be that it doesn't hurt if there would be
one or two non-stubs only, and useful here and there. Who knows,
maybe the 437 use cases in FreeBSD make a difference which allows
an image to fit in some boundary, or not.
|force. Otherwise, you are just trying to make a name for yourself,
|and I'll let people figure out which one you created just now.
People are strange sometimes.
--steffen
