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 1 of 4  [1] 2 3 4  Next page →

#101294 — standard error codes

I think the C standard should add a type and values for 
common errors to void conversions between types/values.

For instance:

enum {
    thrd_success = /* unspecified */,
    thrd_nomem = /* unspecified */,
    thrd_timedout = /* unspecified */,
    thrd_busy = /* unspecified */,
    thrd_error = /* unspecified */
};

Theses errors are defined for the thread library.
So now, for each new library they are going to add 
a new error code?

  newlib_success = /* unspecified */,
  newlib_nomem = /* unspecified */,
...


I am creating a program, so do I need to create my 
own error code? Let's say I want to share some of 
my libraries with someone else and each one of us
have different error codes/values.

What do you think? How do you do?

[toc] | [next] | [standalone]

#101302

On Sunday, January 8, 2017 at 2:34:30 PM UTC, Thiago Adams wrote:
> I think the C standard should add a type and values for 
> common errors to void conversions between types/values.
> 
> For instance:
> 
> enum {
>     thrd_success = /* unspecified */,
>     thrd_nomem = /* unspecified */,
>     thrd_timedout = /* unspecified */,
>     thrd_busy = /* unspecified */,
>     thrd_error = /* unspecified */
> };
> 
> Theses errors are defined for the thread library.
> So now, for each new library they are going to add 
> a new error code?
> 
>   newlib_success = /* unspecified */,
>   newlib_nomem = /* unspecified */,
> ...
> 
> 
> I am creating a program, so do I need to create my 
> own error code? Let's say I want to share some of 
> my libraries with someone else and each one of us
> have different error codes/values.
> 
> What do you think? How do you do?
>
Absolutely.

I use -1 for out of memory. Note that for a function, called #
"Malcolm-functions" in this ng by popular demand (a Malcolm function
is a mapping of input bits to output bits with no IO) there are
only two possible errors - invalid parameters or out of memory.
usually you want to i=assert-fail invalid parameters, so the
scheme is pretty simple. ) for success, -1 for out of memory,
in functions which don't return allocated pointers, where obviously
NULL indicates the out of memory condition.

What else can go wrong. Well if a function is a parser, you can also
have invalidly formatted input. The difference is that you can't 
reasonably demand that the calling programmer pass only well-formed
input, because to check he's got to effectively implement the parser
himself. So you need parse errors as part of flow control where
input is held in memory. Where input is a file, you will normally
but not always chuck out the whole file, and users really often like
line number and context. (That's often hard to provide).
But the code can be -3. 

-2 I keep for IO errors. By an IO error, I mean some physical 
problem with a device attached to the computer. Here, you normally
can't diagnose the problem, you've just got to abort that operation
and hope that something else on the system can trouble shoot for
your user.

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

#101334

On Sunday, January 8, 2017 at 5:05:41 PM UTC-2, Malcolm McLean wrote:
> On Sunday, January 8, 2017 at 2:34:30 PM UTC, Thiago Adams wrote:
> > I think the C standard should add a type and values for 
> > common errors to void conversions between types/values.
> > 
> > For instance:
> > 
> > enum {
> >     thrd_success = /* unspecified */,
> >     thrd_nomem = /* unspecified */,
> >     thrd_timedout = /* unspecified */,
> >     thrd_busy = /* unspecified */,
> >     thrd_error = /* unspecified */
> > };
> > 
> > Theses errors are defined for the thread library.
> > So now, for each new library they are going to add 
> > a new error code?
> > 
> >   newlib_success = /* unspecified */,
> >   newlib_nomem = /* unspecified */,
> > ...
> > 
> > 
> > I am creating a program, so do I need to create my 
> > own error code? Let's say I want to share some of 
> > my libraries with someone else and each one of us
> > have different error codes/values.
> > 
> > What do you think? How do you do?
> >
> Absolutely.
> 
> I use -1 for out of memory. Note that for a function, called #
> "Malcolm-functions" in this ng by popular demand (a Malcolm function
> is a mapping of input bits to output bits with no IO) there are
> only two possible errors - invalid parameters or out of memory.
> usually you want to i=assert-fail invalid parameters, so the
> scheme is pretty simple. ) for success, -1 for out of memory,
> in functions which don't return allocated pointers, where obviously
> NULL indicates the out of memory condition.

0 for success? 

I see the advantages of returning -1 (numbers) is not to include or 
declare something new.
The disadvantage is that if you need to search for "memory fail"  
you will get a lot of unrelated lines. If you need refactoring 
as well or if you use wrong types my mistake.

I don't use 0 for success because I cannot use in ifs

if (F())
{
  //success
}

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

#101336

On Monday, January 9, 2017 at 11:33:55 AM UTC, Thiago Adams wrote:
> On Sunday, January 8, 2017 at 5:05:41 PM UTC-2, Malcolm McLean wrote:
> 
> 0 for success? 
> 
> I see the advantages of returning -1 (numbers) is not to include or 
> declare something new.
> The disadvantage is that if you need to search for "memory fail"  
> you will get a lot of unrelated lines. If you need refactoring 
> as well or if you use wrong types my mistake.
> 
> I don't use 0 for success because I cannot use in ifs
> 
> if (F())
> {
>   //success
> }
>
0 for success, -1 for fail is one of the standard conventions.

My view is that a normal function (not a built-in mathematical 
function like sin or cos, but a standard user function like 
getCandidateCornerPixels() should be the only thing on the
line, together with it's return assignment if appropriate.

Otherwise code becomes to hard to read. if for success which
is almost always taken also introduces a level of nesting. The
rule of three says keep nesting to three levels, so they are
too precious to waste like that.\

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

#101344

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> 0 for success, -1 for fail is one of the standard conventions.

I think 0 for success, 1 for failure is more common.  Or 0 for success,
non-0 for failure.

> My view is that a normal function (not a built-in mathematical 
> function like sin or cos, but a standard user function like 
> getCandidateCornerPixels() should be the only thing on the
> line, together with it's return assignment if appropriate.
>
> Otherwise code becomes to hard to read. if for success which
> is almost always taken also introduces a level of nesting. The
> rule of three says keep nesting to three levels, so they are
> too precious to waste like that.\

Fortunately for the rest of us, the "rule of three" exists only in your
mind.

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

#101347

On Monday, January 9, 2017 at 3:06:31 PM UTC-2, Keith Thompson wrote:
> Malcolm McLean  writes:
> [...]
> > 0 for success, -1 for fail is one of the standard conventions.
> 
> I think 0 for success, 1 for failure is more common.  Or 0 for success,
> non-0 for failure.
> 

I guess some standard functions try to use some result 
and adapt it to show errors without to use/create a new 
type for error.

For instance:

char *fgets( char *str, int count, FILE* stream );

Return value
str on success, null pointer on failure.


Using the same logic, for array_push for instance, I could
return -1 if the element was not added, or return the 
number of elements after insertion. 

The same for array_reserve (allocates n elements).

I have a 

//Sets the newValue on s
String_Set(String* s, const char* newValue);

In this case I could return NULL for error and 
s in success.
Or the number of characters copied. -1 for failure.

So, in brief, is to use something some state present 
on computation and return an invalid value of this state 
to indicate error.

If the state is size/count then -1.
If the state if pointer NULL.
This is not always easy..like atoi.
atoi could return the number of characters used or -1 on error.
 

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

#101352 — Re: standard error codes

On 09/01/2017 17:52, Thiago Adams wrote:
> On Monday, January 9, 2017 at 3:06:31 PM UTC-2, Keith Thompson wrote:
>> Malcolm McLean  writes:
>> [...]
>>> 0 for success, -1 for fail is one of the standard conventions.
>>
>> I think 0 for success, 1 for failure is more common.  Or 0 for success,
>> non-0 for failure.
>>
>
> I guess some standard functions try to use some result
> and adapt it to show errors without to use/create a new
> type for error.
>
> For instance:
>
> char *fgets( char *str, int count, FILE* stream );
>
> Return value
> str on success, null pointer on failure.
>
>
> Using the same logic, for array_push for instance, I could
> return -1 if the element was not added, or return the
> number of elements after insertion.
>
> The same for array_reserve (allocates n elements).

C's zero-based indexing makes it harder to use 0 for failure and N for 
success.

For example, for a routine that searches an array indexed 0 to N-1 for 
the index of some value, 0 must be one of the return values denoting 
success. With a one-based list, then you can't do:

   if (find(A,N,X)) ...

instead if might need to be:

   if (find(A,N,X) != NOTFOUND) ...

or '!= -1' or '>= 0'.

-- 
Bartc

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

#101354 — Re: standard error codes

On 09/01/2017 21:50, BartC wrote:

> C's zero-based indexing makes it harder to use 0 for failure and N for
> success.
>
> For example, for a routine that searches an array indexed 0 to N-1 for
> the index of some value, 0 must be one of the return values denoting
> success. With a one-based list, then you can't do:
>
>   if (find(A,N,X)) ...

I mean you can't use this for zero-based arrays as you can for 
one-based. It's just another range of applications where using 0 to 
conveniently signal failure can't used, and that means thinking up some 
other scheme, that can't be quite as simple or intuitive.

Another example is strcmp(), where you have to remember to compare 
against 0 to ensure two strings are the same, or two blocks of bytes are 
the same when using memcmp, as there is no streq or memeq. And you don't 
always remember...

-- 
bartc

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

#101355 — Re: standard error codes

On Monday, January 9, 2017 at 4:36:22 PM UTC-6, Bart wrote:
> Another example is strcmp(), where you have to remember to compare 
> against 0 to ensure two strings are the same, or two blocks of bytes are 
> the same when using memcmp, as there is no streq or memeq. And you don't 
> always remember...

I find it curious that functions for testing equality haven't emerged, since
in some cases it may be much faster to report that things are unequal than
to report which is greater (e.g. on a little-endian machine which supports
unaligned accesses, a memeq function could easily compare chunks of four or
eight bytes at a time for equality without having to worry about byte order,
but a normal relational comparison would award higher weight to the last byte
of a chunk than the first.  If all code cares about is whether things are
equal, the extra effort required for a relational comparison would be wasted.

On the other hand, it might be useful to have a version of memeq which if
two regions are equal will return null, and if they're unequal will return
a pointer to the first different byte in the source, as well as a variant
which when given unequal pointers will return a pointer to a byte in the
source which is at or before the point of mismatch.  The latter could be
useful in code to sort long strings of known lengths--if a Quicksort knows
none of the strings in a partition differ in any of the first 100 bytes,
there's really no reason for sorting operations on that partition to look
at the first 100 bytes of any strings.

While it might seem more useful to have a comparison function yield an exact pointer, that would require code to expend effort finding where within a multi-byte chunk the mismatch occurred--effort that might not be recouped.

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

#101356 — Re: standard error codes

On 09/01/2017 22:51, supercat@casperkitty.com wrote:
> On Monday, January 9, 2017 at 4:36:22 PM UTC-6, Bart wrote:
>> Another example is strcmp(), where you have to remember to compare
>> against 0 to ensure two strings are the same, or two blocks of bytes are
>> the same when using memcmp, as there is no streq or memeq. And you don't
>> always remember...
>
> I find it curious that functions for testing equality haven't emerged, since
> in some cases it may be much faster to report that things are unequal than
> to report which is greater (e.g. on a little-endian machine which supports
> unaligned accesses, a memeq function could easily compare chunks of four or
> eight bytes at a time for equality without having to worry about byte order,
> but a normal relational comparison would award higher weight to the last byte
> of a chunk than the first.  If all code cares about is whether things are
> equal, the extra effort required for a relational comparison would be wasted.

Even if the same machine string-compare instructions are used for both 
kinds of compare, you don't have the messing about setting up a result 
of -1, 0 and 1, instead of just 0 and 1.

(Maybe a compiler could optimise 'if (strncmp(s,t,n)==0)' to a fast 
n-byte equality check, but you don't want to leave everything to the 
capabilities of the compiler, as these will vary.

Besides the programmer wants to write: 'if (streq(s,t,n))', or 'if 
(memeq(s,t,n))' (which also does the job of strncmp(s,t,n)==0).)

> On the other hand, it might be useful to have a version of memeq which if
> two regions are equal will return null,

No, you want to keep these simple. The most common use I think is to 
find whether two blocks of memory are the same or not, not find out 
where they are different. For that you can use different functions.

So if you're searching a hash containing counted strings, you need to 
quickly check memeq(s,t,n) returns true to confirm a match, otherwise 
proceed to the next entry. (You will of course have already checked the 
strings match in length. You don't care whether s is greater or less 
than t.)

-- 
Bartc

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

#101357 — Re: standard error codes

On Monday, January 9, 2017 at 5:39:46 PM UTC-6, Bart wrote:
> > On the other hand, it might be useful to have a version of memeq which if
> > two regions are equal will return null,
> 
> No, you want to keep these simple. The most common use I think is to 
> find whether two blocks of memory are the same or not, not find out 
> where they are different. For that you can use different functions.

By what means would you suggest that something like a Quicksort of long
strings would be able to avoid redundant comparisons involving parts of
strings which have already been observed to match, while retaining the
use of any string-comparison acceleration features a platform might
provide?

There could be advantages to having a "pure" memory-equality test function
which could be performed on disjoint parts of the array in parallel and
stop as soon as a mismatch is found anywhere, but in most cases a function
that processes chunks of memory in order and returns the address of the
first chunk where a mismatch was found would be essentially as cheap as one
which simply reports equal or not-equal in the most efficient way possible.

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

#101358 — Re: standard error codes

On Monday, January 9, 2017 at 11:51:15 PM UTC, supe...@casperkitty.com wrote:
> On Monday, January 9, 2017 at 5:39:46 PM UTC-6, Bart wrote:
> > > On the other hand, it might be useful to have a version of memeq which if
> > > two regions are equal will return null,
> > 
> > No, you want to keep these simple. The most common use I think is to 
> > find whether two blocks of memory are the same or not, not find out 
> > where they are different. For that you can use different functions.
> 
> By what means would you suggest that something like a Quicksort of long
> strings would be able to avoid redundant comparisons involving parts of
> strings which have already been observed to match, while retaining the
> use of any string-comparison acceleration features a platform might
> provide?
> 
You code it specially for that dataset. But quicksort shouldn't compare 
any one pair of strings more than once.
Software projects seldom fail because that type of optimisation is not
possible or not attempted. They may fail if it is insisted on and
becomes too complex to manage.

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

#101364 — Re: standard error codes

On Monday, January 9, 2017 at 6:08:20 PM UTC-6, Malcolm McLean wrote:
> You code it specially for that dataset. But quicksort shouldn't compare 
> any one pair of strings more than once.

It frequently compares strings which are known to be between two other
strings which will often have a common prefix, implying that that the
strings being compared will also share that prefix.

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

#101372 — Re: standard error codes

On Tuesday, January 10, 2017 at 2:51:18 AM UTC, supe...@casperkitty.com wrote:
> On Monday, January 9, 2017 at 6:08:20 PM UTC-6, Malcolm McLean wrote:
> > You code it specially for that dataset. But quicksort shouldn't compare 
> > any one pair of strings more than once.
> 
> It frequently compares strings which are known to be between two other
> strings which will often have a common prefix, implying that that the
> strings being compared will also share that prefix.
>
If all the strings have a common prefix, then simply call strcmp(s1 + 10, s2 + 10);
If you've got a few without the common prefix, then almost certainly you're
over-engineering it to try to take advantage of the common prefix. As I
said, few programs fail because that type of optimisation is not attempted.

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

#101387 — Re: standard error codes

On Tuesday, January 10, 2017 at 4:02:40 AM UTC-6, Malcolm McLean wrote:
> If all the strings have a common prefix, then simply call strcmp(s1 + 10, s2 + 10);
> If you've got a few without the common prefix, then almost certainly you're
> over-engineering it to try to take advantage of the common prefix. As I
> said, few programs fail because that type of optimisation is not attempted.

A relational comparison between two strings will generally require *finding*
a common prefix as the first step (start by advancing past the common prefix,
then compare what's left).  During a partitioning step, when each element is
compared with the pivot, the system could keep track of the shortest common
prefix on each side of the pivot.

If it's known in advance that all data items will have a common prefix, one
could simply advance the pointers being compared, but my point was to address
the common situation where it's likely that large groups of strings will
share a significant prefix, but code doesn't know in advance which items will
do so.  Relational operators will generally need to find the length of the
common prefix during operation, so having the system make use of that info
would allow improved performance.

BTW, another advantage of breaking out more kinds of comaprisons is that the
optimal way of performing a comparison will depend upon whether items are
more likely to have a common prefix, or that they're not.  If two things that
are being compared are likely to differ in the first byte, comparing byte
by byte is apt to be more efficient than any other approach.  If they're
likely to match in the first 60,000 bytes, comparing byte by byte is likely
to be much slower than other approaches.  In many cases, a programmer will
know which situation is more likely, but the same function is used for both
cases there will generally be no way for an implementation to know.

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

#101362 — Re: standard error codes

On 09/01/2017 23:51, supercat@casperkitty.com wrote:
> On Monday, January 9, 2017 at 5:39:46 PM UTC-6, Bart wrote:
>>> On the other hand, it might be useful to have a version of memeq which if
>>> two regions are equal will return null,
>>
>> No, you want to keep these simple. The most common use I think is to
>> find whether two blocks of memory are the same or not, not find out
>> where they are different. For that you can use different functions.
>
> By what means would you suggest that something like a Quicksort of long
> strings would be able to avoid redundant comparisons involving parts of
> strings which have already been observed to match, while retaining the
> use of any string-comparison acceleration features a platform might
> provide?

By special functions as I said. But leave memeq doing one simple, 
dedicated task.

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

-- 
Bartc

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

#101390 — Re: standard error codes

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?

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.

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?
(I don't know the answer, and it could vary from one CPU to another.)

If your concern is that returning a negative/zero/positive result
is confusing, that's easily dealt with, either by learning the
convention or by wrapping memcmp/strcmp calls in a macro.

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

#101392 — Re: standard error codes

On Tuesday, January 10, 2017 at 11:07:07 AM UTC-6, Keith Thompson wrote:
> 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?
> (I don't know the answer, and it could vary from one CPU to another.)

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.

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

#101396 — Re: standard error codes

supercat@casperkitty.com writes:
> On Tuesday, January 10, 2017 at 11:07:07 AM UTC-6, Keith Thompson wrote:
>> 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?
>> (I don't know the answer, and it could vary from one CPU to another.)
>
> 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.)

The question remains, is it significantly more efficient to return
a zero/nonzero result than a negative/zero/positive result?

A *meaningful* answer to that question would require actual
measurements, on actual hardware, using an actual proposed
implementation of memeq() and/or streq().  That's more work than I'm
willing to do at the moment, so I personally will be satisified with
an answer of "I don't know".  But I suggest that *someone* would have
to do that work as a prerequisite to seriously considering adding
memeq() and/or streq() to the standard.  If it would significantly
improve performance, I'm all for it.  But the fact that no such
functions exist on my system suggests (but does not prove) that
the performance improvement is not worthwhile.

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

#101400 — Re: standard error codes

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.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web