Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: standard error codes
Date: Tue, 10 Jan 2017 13:00:02 -0800
Organization: None to speak of
Lines: 36
Message-ID: <ln37gqr5pp.fsf@kst-u.example.com>
References: <96e16709-18eb-4399-86c4-a6f30a767df3@googlegroups.com> <212f08fd-b09e-4848-8485-f7480eaaae45@googlegroups.com> <bf564370-cac4-4030-8487-893c5ea71ddc@googlegroups.com> <86260b21-0fa2-42b4-93c6-08e9241d4c17@googlegroups.com> <lnk2a4qi1v.fsf@kst-u.example.com> <64011b84-2f8d-44f2-902a-0eacfcdf630b@googlegroups.com> <o510fi$16v$1@dont-email.me> <o51362$bse$1@dont-email.me> <11823fb6-613e-4283-95e8-dd930e152418@googlegroups.com> <o516ss$qp2$1@dont-email.me> <546841f1-b478-44dc-abc0-22ca4f46e553@googlegroups.com> <o51dsp$eb6$1@dont-email.me> <lnfukqrghw.fsf@kst-u.example.com> <o5387t$vp5$1@dont-email.me> <ln7f62r7xp.fsf@kst-u.example.com> <o53gf8$ls$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="051d99dd7a883013689f38e075ee6474"; logging-data="22461"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2cOkrvtziLFxtRA/l76cb"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:AXgGVSJG7JqO+MopzKuUc7TDcWE= sha1:hFfQfTv/cNEMbsLS4mGUcntD1EQ=
Xref: csiph.com comp.lang.c:101402

BartC <bc@freeuk.com> writes:
> On 10/01/2017 20:12, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> In that case it would be difficult to call, if getting a 1/0 result
>>> means an extra instruction instead of just returning the result of a
>>> subtraction.
>>
>> No, it's not difficult to call.
>
> I mean it's difficult to predict which would be faster; returning 0 or 1 
> (which is more elegant and matches how a million other functions work), 
> or returning some random result which has to be compared against zero.

If a function returns 0 or 1, that result still has to be compared
against zero.

Sure, it's difficult to predict.  It shouldn't be difficult to
measure.  Without such a measurement, I see no reason to spend
any time considering adding memeq() or streq() functions when the
existing memcmp() and strcmp() functions work just fine.

If you're concerned about performance, show some numbers.  If you're
concerned about elegance:

    #define MEMEQ(s1, s2, n) (memcmp((s1), (s2), (n)) == 0)
    #define STREQ(s1, s2)    (strcmp((s1), (s2)) == 0)

(I'm not certain that the parentheses around the argument names are
necessary, but better safe than sorry.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"