Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101294 > unrolled thread

standard error codes

Back to article view | Back to comp.lang.c

Contents

  standard  error codes Thiago Adams <thiago.adams@gmail.com> - 2017-01-08 06:34 -0800
    Re: standard  error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-08 11:05 -0800
      Re: standard  error codes Thiago Adams <thiago.adams@gmail.com> - 2017-01-09 03:33 -0800
        Re: standard  error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-09 04:55 -0800
          Re: standard  error codes Keith Thompson <kst-u@mib.org> - 2017-01-09 09:06 -0800
            Re: standard  error codes Thiago Adams <thiago.adams@gmail.com> - 2017-01-09 09:52 -0800
              Re: standard error codes BartC <bc@freeuk.com> - 2017-01-09 21:50 +0000
                Re: standard error codes BartC <bc@freeuk.com> - 2017-01-09 22:36 +0000
                  Re: standard error codes supercat@casperkitty.com - 2017-01-09 14:51 -0800
                    Re: standard error codes BartC <bc@freeuk.com> - 2017-01-09 23:39 +0000
                      Re: standard error codes supercat@casperkitty.com - 2017-01-09 15:51 -0800
                        Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-09 16:08 -0800
                          Re: standard error codes supercat@casperkitty.com - 2017-01-09 18:51 -0800
                            Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-10 02:02 -0800
                              Re: standard error codes supercat@casperkitty.com - 2017-01-10 07:34 -0800
                        Re: standard error codes BartC <bc@freeuk.com> - 2017-01-10 01:39 +0000
                          Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-10 09:07 -0800
                            Re: standard error codes supercat@casperkitty.com - 2017-01-10 09:59 -0800
                              Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-10 12:02 -0800
                                Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-10 12:53 -0800
                                  Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-10 13:03 -0800
                                    Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-10 15:41 -0800
                                      Re: standard error codes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 02:56 +0000
                                      Re: standard error codes supercat@casperkitty.com - 2017-01-11 07:42 -0800
                                Re: standard error codes supercat@casperkitty.com - 2017-01-10 12:59 -0800
                            Re: standard error codes BartC <bc@freeuk.com> - 2017-01-10 18:14 +0000
                              Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-10 12:12 -0800
                                Re: standard error codes BartC <bc@freeuk.com> - 2017-01-10 20:35 +0000
                                  Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-10 13:00 -0800
                                Re: standard error codes supercat@casperkitty.com - 2017-01-11 08:16 -0800
                                  Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 18:25 +0000
                                    Re: standard error codes BartC <bc@freeuk.com> - 2017-01-11 19:09 +0000
                                      Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-11 12:03 -0800
                                        Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 20:10 +0000
                                          Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-11 12:19 -0800
                                        Re: standard error codes BartC <bc@freeuk.com> - 2017-01-11 20:31 +0000
                                      Re: standard error codes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-11 15:32 -0500
                                        Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 20:48 +0000
                                          Re: standard error codes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-11 15:58 -0500
                                        Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-11 13:01 -0800
                                          Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 21:05 +0000
                                          Re: standard error codes BartC <bc@freeuk.com> - 2017-01-11 21:08 +0000
                                            Re: standard error codes Gareth Owen <gwowen@gmail.com> - 2017-01-11 21:38 +0000
                                              Re: standard error codes BartC <bc@freeuk.com> - 2017-01-11 21:58 +0000
                                              Re: standard error codes David Brown <david.brown@hesbynett.no> - 2017-01-12 12:11 +0100
                                                Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-12 09:28 -0800
                                                  Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 18:06 +0000
                                                    Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-12 11:39 -0800
                                                      Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 19:50 +0000
                                                        Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-12 13:03 -0800
                                                          Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:13 +0000
                                                            Re: standard error codes <william@wilbur.25thandClement.com> - 2017-01-12 20:00 -0800
                                                              Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 01:56 -0800
                                                              Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 12:54 +0000
                                                                Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-13 09:35 -0800
                                                                  Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 17:38 +0000
                                                                    Re: standard error codes James Kuyper <jameskuyper@verizon.net> - 2017-01-13 13:06 -0500
                                                                    Re: standard error codes raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:00 +0000
                                                                      Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-18 12:13 +0000
                                                    Re: standard error codes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-12 16:43 -0800
                                                  Re: standard error codes <william@wilbur.25thandClement.com> - 2017-01-12 19:34 -0800
                                                    Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-13 09:27 -0800
                                              Re: standard error codes raltbos@xs4all.nl (Richard Bos) - 2017-01-12 19:33 +0000
                                                Re: standard error codes Keith Thompson <kst-u@mib.org> - 2017-01-12 12:10 -0800
                                    Re: standard error codes supercat@casperkitty.com - 2017-01-11 11:50 -0800
                                      Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 20:38 +0000
                                    Re: standard error codes jadill33@gmail.com - 2017-01-11 12:26 -0800
                                      Re: standard error codes Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 20:44 +0000
        Re: standard  error codes Keith Thompson <kst-u@mib.org> - 2017-01-09 09:03 -0800
    Re: standard  error codes supercat@casperkitty.com - 2017-01-08 11:40 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#101403 — Re: standard error codes

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, January 10, 2017 at 8:01:26 PM UTC, Keith Thompson wrote:
>> 
>> The question remains, is it significantly more efficient to return
>> a zero/nonzero result than a negative/zero/positive result?
>> 
> C++ std::sort is built on a < operator which returns true if a < b, and
> has to be called a bit clumsily if(!(a < b) && !( b <a)) for equality.
> That gives it a slight benefit over qsort which insists on a three-way
> comparison.

What "slight benefit" are you referring to?  If you mean there's a
performance improvement, do you have measurements?

-- 
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"

[toc] | [prev] | [next] | [standalone]

#101406 — Re: standard error codes

On Tuesday, January 10, 2017 at 9:03:17 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Tuesday, January 10, 2017 at 8:01:26 PM UTC, Keith Thompson wrote:
> >> 
> >> The question remains, is it significantly more efficient to return
> >> a zero/nonzero result than a negative/zero/positive result?
> >> 
> > C++ std::sort is built on a < operator which returns true if a < b, and
> > has to be called a bit clumsily if(!(a < b) && !( b <a)) for equality.
> > That gives it a slight benefit over qsort which insists on a three-way
> > comparison.
> 
> What "slight benefit" are you referring to?  If you mean there's a
> performance improvement, do you have measurements?
> 
If we're sorting on two doubles

return *a < *b;

will be faster than

   return (*a < *b) ? 1 : (*a == *b) ? 0 : -1;

[toc] | [prev] | [next] | [standalone]

#101419 — Re: standard error codes

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Tuesday, January 10, 2017 at 9:03:17 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Tuesday, January 10, 2017 at 8:01:26 PM UTC, Keith Thompson wrote:
>> >> 
>> >> The question remains, is it significantly more efficient to return
>> >> a zero/nonzero result than a negative/zero/positive result?
>> >> 
>> > C++ std::sort is built on a < operator which returns true if a < b, and
>> > has to be called a bit clumsily if(!(a < b) && !( b <a)) for equality.
>> > That gives it a slight benefit over qsort which insists on a three-way
>> > comparison.

It would not be easy to measure since std::sort has the advantage of
being able to inline the calls to the comparison function.  That's
likely to mask any advantage from a less complex function body.

>> What "slight benefit" are you referring to?  If you mean there's a
>> performance improvement, do you have measurements?
>> 
> If we're sorting on two doubles
>
> return *a < *b;
>
> will be faster than
>
>    return (*a < *b) ? 1 : (*a == *b) ? 0 : -1;

  return (*a < *b) - (*a > *b);

will probably be better and (on most architectures) won't have any
branches in it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101437 — Re: standard error codes

On Tuesday, January 10, 2017 at 5:41:36 PM UTC-6, Malcolm McLean wrote:
> If we're sorting on two doubles
> 
> return *a < *b;
> 
> will be faster than
> 
>    return (*a < *b) ? 1 : (*a == *b) ? 0 : -1;

Neither formula will work if the range of elements being sorted may include
NaN values.  If a program performs computations on floating-point values and
then wants to sort the results, it must either:

   1. Use a significantly more complicated function for the comparisons,
      use the newer IEEE comparison functions if an implementation supports
      them (I think they were added to the spec in 2007, but I don't know
      of any way to access such functionality), or else

   2. Precede the sort with a filtering or partitioning step which either:

      a. Replaces NaN values with values that can be ranked transitively

      b. Pulls NaN values to the top or bottom and adjusts the range of
         subscripts to be sorted to ensure it doesn't contain any NaN values.

Unless a compiler knows about the extended IEEE comparison functionality and
can recognize whatever combination of the broken comparison operators a
programmer might use to achieve the necessary semantics, approach #2 is apt
to be faster, but requires an extra step.  Code which uses a three-way
comparison function would typically expect to use approach #1, but code
which uses a templated Quicksort with the < or > operator will have no
choice but to use #2.

[toc] | [prev] | [next] | [standalone]

#101401 — Re: standard error codes

On Tuesday, January 10, 2017 at 2:01:26 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> > On many architectures, a memory-compare function which is optimized for the
> > case where blocks will have a long common prefix (or match entirely) will be
> > able to compare multiple bytes at once.  If code is only comparing one byte
> > at a time, returning the result of the comparison will be essentially "free",
> > but code that compares one byte at a time will on many platforms be much
> > slower than code which compares multiple bytes.
> 
> I didn't say the code compares one byte at a time.  I haven't
> looked at the source, so I don't know whether it does or not,
> but I suspect it's well optimized for aligned buffers.
> 
> Whether it compares bytes or words, it has to return a result, and
> it's going to have to be able to do some extra work if there's a
> partial word at the end.  (Comparing two aligned 1023-byte buffers,
> it might do 127 8-byte word comparisons and then deal with the
> final 7 bytes in more detail.)

In the scenario where both buffers are aligned and their size is a multiple
of the word size, an equality test won't require any partial-word handling.
Resolving which of two unequal words should be considered greater, however,
would require additional processing when using commonplace little-endian
machines.

A string-compare function by contrast is going to need to examine every byte
of at least one of the operands regardless of alignment.

[toc] | [prev] | [next] | [standalone]

#101393 — Re: standard error codes

On 10/01/2017 17:07, Keith Thompson wrote:
> BartC <bc@freeuk.com> 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.

> 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!

> 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!

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.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101397 — Re: standard error codes

BartC <bc@freeuk.com> writes:
> On 10/01/2017 17:07, Keith Thompson wrote:
>> BartC <bc@freeuk.com> 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  <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"

[toc] | [prev] | [next] | [standalone]

#101399 — Re: standard error codes

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.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101402 — Re: standard error codes

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"

[toc] | [prev] | [next] | [standalone]

#101441 — Re: standard error codes

On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
> It would be odd to add memeq() but not streq() to the standard.

How many str* functions are used be even 0.1% of C programs?  The strlen
function is essentially as good and safe as any other alternative in the
common situation where code receives a pointer to a string held in a
buffer of unknown size, so it gets used quite a bit.  In many cases,
however, strlen() can be combined with mem* functions to yield faster
and safer code than trying to use other str* functions.

Given that there are many holes in the str* functions far worse than the
lack of an streq function, it would be odd to add streq without fixing all
those other holes first.

[toc] | [prev] | [next] | [standalone]

#101446 — Re: standard error codes

On 11/01/17 16:16, supercat@casperkitty.com wrote:
> On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
>> It would be odd to add memeq() but not streq() to the standard.
>
> How many str* functions are used be even 0.1% of C programs?

I'll have 'em if you don't want 'em.

I haven't done the arithmetic, so I don't know about "most", but I would 
certainly say that /many/ of my C programs use str* functions, and it 
may even be "most".

> The strlen
> function is essentially as good and safe as any other alternative in the
> common situation where code receives a pointer to a string held in a
> buffer of unknown size, so it gets used quite a bit.  In many cases,
> however, strlen() can be combined with mem* functions to yield faster
> and safer code than trying to use other str* functions.
>
> Given that there are many holes in the str* functions far worse than the
> lack of an streq function, it would be odd to add streq without fixing all
> those other holes first.

Yes, I'd agree with that. We don't need a streq function. What's wrong 
with strcmp?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101447 — Re: standard error codes

On 11/01/2017 18:25, Richard Heathfield wrote:
> On 11/01/17 16:16, supercat@casperkitty.com wrote:
>> On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
>>> It would be odd to add memeq() but not streq() to the standard.
>>
>> How many str* functions are used be even 0.1% of C programs?
>
> I'll have 'em if you don't want 'em.
>
> I haven't done the arithmetic, so I don't know about "most", but I would
> certainly say that /many/ of my C programs use str* functions, and it
> may even be "most".
>
>> The strlen
>> function is essentially as good and safe as any other alternative in the
>> common situation where code receives a pointer to a string held in a
>> buffer of unknown size, so it gets used quite a bit.  In many cases,
>> however, strlen() can be combined with mem* functions to yield faster
>> and safer code than trying to use other str* functions.
>>
>> Given that there are many holes in the str* functions far worse than the
>> lack of an streq function, it would be odd to add streq without fixing
>> all
>> those other holes first.
>
> Yes, I'd agree with that. We don't need a streq function. What's wrong
> with strcmp?

Because 99% of all calls to strcmp use it to compare for string equality?

I've looked at some codebases and the overwhelming use of strcmp seems 
to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously 
like a test for equality.

In one or two places, I saw a call like this: if (strcmp(s,t)), which is 
even less intuitive (I think it tests whether s is not equal to t).

With streq, those first calls would look like this:

    if (streq(s,t))

and the second like this:

    if ( !streq(s,t))

In theory, because could create a streq-like function using macros or a 
wrapper, but someone neglected to tell the people who wrote this code!

It doesn't happen.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101449 — Re: standard error codes

BartC <bc@freeuk.com> writes:
> On 11/01/2017 18:25, Richard Heathfield wrote:
[...]
>> Yes, I'd agree with that. We don't need a streq function. What's wrong
>> with strcmp?
>
> Because 99% of all calls to strcmp use it to compare for string equality?

And why is that a problem?

In the early days, it turned out to be just as easy to provide
a string comparison function as a slightly less flexible string
equality function.  It ain't broke.  Why fix it?

> I've looked at some codebases and the overwhelming use of strcmp seems 
> to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously 
> like a test for equality.

They certainly do to any C programmer who's familiar with what strcmp()
does.

> In one or two places, I saw a call like this: if (strcmp(s,t)), which is 
> even less intuitive (I think it tests whether s is not equal to t).

Yes, that's what it does (you're not sure?).  I wouldn't write
it that way myself, but it's perfectly understandable *if* you
understand what strcmp() does.

> With streq, those first calls would look like this:
>
>     if (streq(s,t))
>
> and the second like this:
>
>     if ( !streq(s,t))
>
> In theory, because could create a streq-like function using macros or a 
> wrapper, but someone neglected to tell the people who wrote this code!

Apparently the people who wrote the code didn't feel the need to write a
streq() macro, because they felt, as I do, that calling strcmp()
directly is clear enough.  You seem to be assuming that, if the authors
of the code you're looking at *had only known* that they could wrap
strcmp() in a macro, then of course they would have done so to
make their code clearer.  I disagree.

(BTW, the name "streq" is reserved.  If I felt the need for such a
macro, I might call it "STREQ".)

> It doesn't happen.

Not often, but it can happen in your code if you want it to.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#101451 — Re: standard error codes

On 11/01/17 20:03, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 11/01/2017 18:25, Richard Heathfield wrote:
> [...]
>>> Yes, I'd agree with that. We don't need a streq function. What's wrong
>>> with strcmp?
>>
>> Because 99% of all calls to strcmp use it to compare for string equality?
>
> And why is that a problem?

(a) It isn't, as you and I both know;
(b) it isn't even true.

<snip>

>> In one or two places, I saw a call like this: if (strcmp(s,t)), which is
>> even less intuitive (I think it tests whether s is not equal to t).
>
> Yes, that's what it does (you're not sure?).

BartC has had more than enough opportunity to be taken seriously on this 
newsgroup, and he has spurned every opening. It's up to you, of course, 
but why do you continue to bother with him?

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101452 — Re: standard error codes

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> BartC has had more than enough opportunity to be taken seriously on this 
> newsgroup, and he has spurned every opening. It's up to you, of course, 
> but why do you continue to bother with him?

A good question.  I'll give it some thought.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#101455 — Re: standard error codes

On 11/01/2017 20:03, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> I've looked at some codebases and the overwhelming use of strcmp seems
>> to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously
>> like a test for equality.
>
> They certainly do to any C programmer who's familiar with what strcmp()
> does.
>
>> In one or two places, I saw a call like this: if (strcmp(s,t)), which is
>> even less intuitive (I think it tests whether s is not equal to t).
>
> Yes, that's what it does (you're not sure?).  I wouldn't write
> it that way myself, but it's perfectly understandable *if* you
> understand what strcmp() does.

I understand what strcmp does but I still had to think about it.

The point is it should be obvious. strcmp used that way isn't.

Do you think if people could write (s != t), or (!streq(s,t)), they 
would choose to write it as (strcmp(s,t)) because it is just as clear? 
It isn't!

>> In theory, [...] could create a streq-like function using macros or a
>> wrapper, but someone neglected to tell the people who wrote this code!
>
> Apparently the people who wrote the code didn't feel the need to write a
> streq() macro, because they felt, as I do, that calling strcmp()
> directly is clear enough.

I'm looking at an amalgamation of gcc source files. That uses just such 
a macro, '# define STREQ(s1, s2) ((strcmp (s1, s2) == 0))' that is used 
between lines 4,000 to 21,000, presumably corresponding to one module. 
Everywhere else in the 753,000 Loc file uses strcmp. And I haven't yet 
found a call to strcmp that tests whether it's less or greater than zero.

   You seem to be assuming that, if the authors
> of the code you're looking at *had only known* that they could wrap
> strcmp() in a macro, then of course they would have done so to
> make their code clearer.  I disagree.

One contributor at least obviously found it clearer! But it sticks out 
like a sore thumb. That's why these things should be standardised.

> (BTW, the name "streq" is reserved.  If I felt the need for such a
> macro, I might call it "STREQ".)
>
>> It doesn't happen.
>
> Not often, but it can happen in your code if you want it to.

Not really. If I wanted to post some code here, I would need to drag in 
my own private library of macros too, containing, apart from STREQ, FOR, 
REPEATN, LEN and all the rest. That would nearly be as bad as using 
BEGIN, END instead of braces. Sometimes I just want to write standard code!

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#101456 — Re: standard error codes

On Wednesday January 11 2017 14:09, in comp.lang.c, "BartC" <bc@freeuk.com> 
wrote:

> On 11/01/2017 18:25, Richard Heathfield wrote:
>> On 11/01/17 16:16, supercat@casperkitty.com wrote:
>>> On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
>>>> It would be odd to add memeq() but not streq() to the standard.
>>>
>>> How many str* functions are used be even 0.1% of C programs?
>>
>> I'll have 'em if you don't want 'em.
>>
>> I haven't done the arithmetic, so I don't know about "most", but I would
>> certainly say that /many/ of my C programs use str* functions, and it
>> may even be "most".
>>
>>> The strlen
>>> function is essentially as good and safe as any other alternative in the
>>> common situation where code receives a pointer to a string held in a
>>> buffer of unknown size, so it gets used quite a bit.  In many cases,
>>> however, strlen() can be combined with mem* functions to yield faster
>>> and safer code than trying to use other str* functions.
>>>
>>> Given that there are many holes in the str* functions far worse than the
>>> lack of an streq function, it would be odd to add streq without fixing
>>> all
>>> those other holes first.
>>
>> Yes, I'd agree with that. We don't need a streq function. What's wrong
>> with strcmp?
> 
> Because 99% of all calls to strcmp use it to compare for string equality?
> 
> I've looked at some codebases and the overwhelming use of strcmp seems
> to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously
> like a test for equality.
> 
> In one or two places, I saw a call like this: if (strcmp(s,t)), which is
> even less intuitive (I think it tests whether s is not equal to t).
> 
> With streq, those first calls would look like this:
> 
>     if (streq(s,t))
> 
> and the second like this:
> 
>     if ( !streq(s,t))
> 
> In theory, because could create a streq-like function using macros or a
> wrapper, but someone neglected to tell the people who wrote this code!
> 
> It doesn't happen.

I would interpret the observation a bit differently:

"A C programmer could create a trivial macro or function wrapper around 
strcmp() to compare two strings, returning an appropriate truth value for 
string equality/inequality. However, as this sort of macro/function would add 
no benefits over the existing strcmp() implementation, such a macro/function 
is rarely, if ever, written."

#define streq(s,t) (!!strcmp(s,t))


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#101460 — Re: standard error codes

On 11/01/17 20:32, Lew Pitcher wrote:
> On Wednesday January 11 2017 14:09, in comp.lang.c, "BartC" <bc@freeuk.com>
> wrote:
>
>> On 11/01/2017 18:25, Richard Heathfield wrote:
>>> On 11/01/17 16:16, supercat@casperkitty.com wrote:
>>>> On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
>>>>> It would be odd to add memeq() but not streq() to the standard.
>>>>
>>>> How many str* functions are used be even 0.1% of C programs?
>>>
>>> I'll have 'em if you don't want 'em.
>>>
>>> I haven't done the arithmetic, so I don't know about "most", but I would
>>> certainly say that /many/ of my C programs use str* functions, and it
>>> may even be "most".
>>>
>>>> The strlen
>>>> function is essentially as good and safe as any other alternative in the
>>>> common situation where code receives a pointer to a string held in a
>>>> buffer of unknown size, so it gets used quite a bit.  In many cases,
>>>> however, strlen() can be combined with mem* functions to yield faster
>>>> and safer code than trying to use other str* functions.
>>>>
>>>> Given that there are many holes in the str* functions far worse than the
>>>> lack of an streq function, it would be odd to add streq without fixing
>>>> all
>>>> those other holes first.
>>>
>>> Yes, I'd agree with that. We don't need a streq function. What's wrong
>>> with strcmp?
>>
>> Because 99% of all calls to strcmp use it to compare for string equality?
>>
>> I've looked at some codebases and the overwhelming use of strcmp seems
>> to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously
>> like a test for equality.
>>
>> In one or two places, I saw a call like this: if (strcmp(s,t)), which is
>> even less intuitive (I think it tests whether s is not equal to t).
>>
>> With streq, those first calls would look like this:
>>
>>     if (streq(s,t))
>>
>> and the second like this:
>>
>>     if ( !streq(s,t))
>>
>> In theory, because could create a streq-like function using macros or a
>> wrapper, but someone neglected to tell the people who wrote this code!
>>
>> It doesn't happen.
>
> I would interpret the observation a bit differently:
>
> "A C programmer could create a trivial macro or function wrapper around
> strcmp() to compare two strings, returning an appropriate truth value for
> string equality/inequality. However, as this sort of macro/function would add
> no benefits over the existing strcmp() implementation, such a macro/function
> is rarely, if ever, written."
>
> #define streq(s,t) (!!strcmp(s,t))

Am I missing something? Surely you mean

#define streq(s, t) (!strcmp(s,t))

? (Assuming you want it to return true (non-0) if the strings are 
equal.) (And I'd put some more ()s in there..., and I'd choose a 
different name, and...)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101463 — Re: standard error codes

On Wednesday January 11 2017 15:48, in comp.lang.c, "Richard Heathfield" 
<rjh@cpax.org.uk> wrote:

> On 11/01/17 20:32, Lew Pitcher wrote:
>> On Wednesday January 11 2017 14:09, in comp.lang.c, "BartC" <bc@freeuk.com>
>> wrote:
>>
>>> On 11/01/2017 18:25, Richard Heathfield wrote:
>>>> On 11/01/17 16:16, supercat@casperkitty.com wrote:
>>>>> On Tuesday, January 10, 2017 at 2:10:56 PM UTC-6, Keith Thompson wrote:
>>>>>> It would be odd to add memeq() but not streq() to the standard.
>>>>>
>>>>> How many str* functions are used be even 0.1% of C programs?
>>>>
>>>> I'll have 'em if you don't want 'em.
>>>>
>>>> I haven't done the arithmetic, so I don't know about "most", but I would
>>>> certainly say that /many/ of my C programs use str* functions, and it
>>>> may even be "most".
>>>>
>>>>> The strlen
>>>>> function is essentially as good and safe as any other alternative in the
>>>>> common situation where code receives a pointer to a string held in a
>>>>> buffer of unknown size, so it gets used quite a bit.  In many cases,
>>>>> however, strlen() can be combined with mem* functions to yield faster
>>>>> and safer code than trying to use other str* functions.
>>>>>
>>>>> Given that there are many holes in the str* functions far worse than the
>>>>> lack of an streq function, it would be odd to add streq without fixing
>>>>> all
>>>>> those other holes first.
>>>>
>>>> Yes, I'd agree with that. We don't need a streq function. What's wrong
>>>> with strcmp?
>>>
>>> Because 99% of all calls to strcmp use it to compare for string equality?
>>>
>>> I've looked at some codebases and the overwhelming use of strcmp seems
>>> to either use strcmp(s,t)==0, or !strcmp(s,t). Neither looks obviously
>>> like a test for equality.
>>>
>>> In one or two places, I saw a call like this: if (strcmp(s,t)), which is
>>> even less intuitive (I think it tests whether s is not equal to t).
>>>
>>> With streq, those first calls would look like this:
>>>
>>>     if (streq(s,t))
>>>
>>> and the second like this:
>>>
>>>     if ( !streq(s,t))
>>>
>>> In theory, because could create a streq-like function using macros or a
>>> wrapper, but someone neglected to tell the people who wrote this code!
>>>
>>> It doesn't happen.
>>
>> I would interpret the observation a bit differently:
>>
>> "A C programmer could create a trivial macro or function wrapper around
>> strcmp() to compare two strings, returning an appropriate truth value for
>> string equality/inequality. However, as this sort of macro/function would
>> add no benefits over the existing strcmp() implementation, such a
>> macro/function is rarely, if ever, written."
>>
>> #define streq(s,t) (!!strcmp(s,t))
> 
> Am I missing something? Surely you mean
> 
> #define streq(s, t) (!strcmp(s,t))

My bad. Sorry

> ? (Assuming you want it to return true (non-0) if the strings are
> equal.) (And I'd put some more ()s in there..., and I'd choose a
> different name, and...)
> 


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#101464 — Re: standard error codes

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> #define streq(s,t) (!!strcmp(s,t))

Was the logical error deliberate?

-- 
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"

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web