Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: standard error codes Date: Tue, 10 Jan 2017 12:12:02 -0800 Organization: None to speak of Lines: 67 Message-ID: References: <96e16709-18eb-4399-86c4-a6f30a767df3@googlegroups.com> <212f08fd-b09e-4848-8485-f7480eaaae45@googlegroups.com> <86260b21-0fa2-42b4-93c6-08e9241d4c17@googlegroups.com> <64011b84-2f8d-44f2-902a-0eacfcdf630b@googlegroups.com> <11823fb6-613e-4283-95e8-dd930e152418@googlegroups.com> <546841f1-b478-44dc-abc0-22ca4f46e553@googlegroups.com> 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+Qq0ZJeWxTRxN9K2DDA22E" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:4YxgntBLmTncazrEtPCaBq79qxM= sha1:ENqGvelOV+GyMmJbBnNmx4PiMOA= Xref: csiph.com comp.lang.c:101397 BartC writes: > On 10/01/2017 17:07, Keith Thompson wrote: >> BartC writes: >> [...] >>> (I just tested one of my intepreters counting the number of string >>> equal/not equal ops, and the number of relative compare ops. The task >>> was running a compiler. All ops were on counted strings. Results: >>> >>> string == != 140221 instances >>> string < <= >= > 0 instances >>> >>> So memeq is needed!) >> >> memeq or streq, or both? > > These are counted strings so memeq. streq might be useful for strings > for lengths are not known. If there was a choice of only one, then I > think memeq would be more useful. It would be odd to add memeq() but not streq() to the standard. >> Either one would be needed only if replacing calls to memcmp/strcmp >> by call to an optimized memeq/streq saves enough time to be >> significant. If you can demonstrate that (memeq(x, y)) can be >> significantly faster than (memcmp(x, y) == 0), then you'll have a >> valid argument. > > If memcmp didn't exist and you wrote your own routine to compare two > blocks of N bytes for equality, would you bother to also find out which > of two unequal blocks was 'greater than' the other (once you've defined > what that means), and set up a -1, 0 or 1 output code? > > I'm guessing you would take the simple approach! But memcmp() does exist. Given that, the simple approach is to call memcmp() and compare the result to 0 if all I care about is (in)equality. There's a sample implementation of strcmp() (but not memcmp() in K&R1. It compares a byte at a time (reasonable in that context), and distinguishing between less-than and greater-than (likely more useful for strings than for byge buffers) is essentially free. It's the difference between a subtraction and a comparison. >> An experiment I did the other day shows that, at least for some >> implementations, memcmp() returns the difference between the first >> corresponding bytes that differ. Would returning a zero/nonzero >> result be faster than returning the result of a subtraction? > > OK, so the result isn't even -1, 0 or 1! Right. You could have found that out by reading the standard, or a man page. You really should understand the existing standard library functions before suggesting new ones. > 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. C programmers have been doing it for decades. Is "> 0" harder to type than "== 1"? -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"