Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101294 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-01-08 06:34 -0800 |
| Last post | 2017-01-08 11:40 -0800 |
| Articles | 10 on this page of 70 — 14 participants |
Back to article view | Back to comp.lang.c
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2017-01-12 19:34 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <3gulkd-1ds.ln1@wilbur.25thandClement.com> |
| In reply to | #101531 |
Keith Thompson <kst-u@mib.org> wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 11/01/17 22:38, Gareth Owen wrote: >>> BartC <bc@freeuk.com> writes: >>>> It just reinforces my point that strcmp by itself is unintuitive. >> >> I would say that strcmp is a useful function, but the name is not ideal. >> It would make more sense, IMHO, if it were called "strdiff". > > strdiff would be a good name for a function that returns a Boolean > result indicating whether its argument strings differ. strcmp can > be used that way, but IMHO the name strdiff would be more misleading > than strcmp. What it really does is *compare* two strings. > > It's nice for a function that returns a result to have a name > that relfects the meaning of that result, but it's not always > practical. And in the case of strcmp, you can think of the > negative/zero/positive result it returns as a *comparison*, which > makes the name strcmp, perfectly sensible. It's not the most > intuitive name, but it's more than good enough. What would be more intuitive? (Maybe you're just being polite?) The spaceship operator (<=>) in Perl is used to test whether one number is less-than, equal-to, or greater-than another number. In other languages it's called the three-way comparison operator. The equivalent string operator in Perl is literally "cmp". The cmp operator, like strcmp, is a lexical comparison of strings. strdiff sounds odd to me. A comparison with a boolean result is normally phrased as a test for equality. The _difference_ of two things typically comes neither from a boolean set (like for equality) nor ternary set (like for the three-way comparison). > (A somewhat irrelevant example: the Unix "diff" command returns > a result indicating success if the two files do *not* differ. > That probably bothered me for a couple of minutes when I first > learned about it.) > So does the cmp(1) utility, which likewise gives me pause everytime I use it. More so than diff as I tend to use diff interactively, ignoring the exit code. Whereas I use cmp -s just for the exit code. It doesn't help (my confusion, nor this discussion!) that in the Unix shell an exit status of 0 evaluates as true, and non-0 as false. It strikes me that your example of diff may not only be relevant, but perhaps be one of the most relevant observations in this thread! - Bill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 09:27 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <lnlguena3w.fsf@kst-u.example.com> |
| In reply to | #101574 |
<william@wilbur.25thandClement.com> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> It's nice for a function that returns a result to have a name
>> that relfects the meaning of that result, but it's not always
>> practical. And in the case of strcmp, you can think of the
>> negative/zero/positive result it returns as a *comparison*, which
>> makes the name strcmp, perfectly sensible. It's not the most
>> intuitive name, but it's more than good enough.
>
> What would be more intuitive? (Maybe you're just being polite?)
I was comparing the name strcmp to other names for other functions, not
necessarily to alternative names for strcmp itself. For example, the
time() function has a nicely intuitive name that describes the meaning
of the value it returns.
Given what strcmp() does, the name "strcmp" is probably about as good as
anything I could think of. (Some might complain about the terseness,
compressing "string" to "str" and "compare" to "cmp", but that's another
matter.)
[...]
--
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]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-12 19:33 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <5877d9e5.1558312@news.xs4all.nl> |
| In reply to | #101467 |
Gareth Owen <gwowen@gmail.com> wrote: > BartC <bc@freeuk.com> writes: > > > It just reinforces my point that strcmp by itself is unintuitive. > > Matlab has a boatload of functions that shares names with functions in > the C library. Almost without exception (no pun intended) they function > in an identical manner (modulo a completely different notion of error > handling). > > The exception is strcmp() which returns 1 if the two arguments are the > same, and 0 if not. So what you're saying is, Matlab is incapable of telling you whether a string comes before or after another string? Well, there goes the sorted list... Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-12 12:10 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <lnk2a0nioe.fsf@kst-u.example.com> |
| In reply to | #101540 |
raltbos@xs4all.nl (Richard Bos) writes:
> Gareth Owen <gwowen@gmail.com> wrote:
>> BartC <bc@freeuk.com> writes:
>> > It just reinforces my point that strcmp by itself is unintuitive.
>>
>> Matlab has a boatload of functions that shares names with functions in
>> the C library. Almost without exception (no pun intended) they function
>> in an identical manner (modulo a completely different notion of error
>> handling).
>>
>> The exception is strcmp() which returns 1 if the two arguments are the
>> same, and 0 if not.
>
> So what you're saying is, Matlab is incapable of telling you whether a
> string comes before or after another string? Well, there goes the sorted
> list...
Quoting https://www.mathworks.com/help/matlab/ref/strcmp.html :
With string arrays, you can use relational operators (==, ~=,
<, >, <=, >=) instead of strcmp. You can compare and sort string
arrays just as you can with numeric arrays.
I don't now how Matlab deals with strings and arrays, but I presume this
gives you the ability to do something like C's strcmp().
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-11 11:50 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <6d8f2d39-af01-4af7-a8d0-36e207857b52@googlegroups.com> |
| In reply to | #101446 |
On Wednesday, January 11, 2017 at 12:25:52 PM UTC-6, Richard Heathfield wrote: > On 11/01/17 16:16, supercat wrote: > > 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". How many str* functions do you use? Do you use strcat or strncat? How about strtok? I should have mentioned strchr and strcmp as two which have decent use cases, though code which wants to use strings efficiently should generally keep track of their length, and if strings' lengths are known the memchr function can be significantly more efficient than strchr. Comparing the efficiency of strcmp and memcmp is a bit more difficult because the latter can be optimized for comparisons of things which are likely to share a significant common prefix while the former cannot. If strings are likely to have early mismatches, strcmp may be more efficient than a memcmp which is optimized for the long-common-prefix case, even though a memcmp that was optimized for early-exit cases could be more efficient yet in those cases.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-11 20:38 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o5650h$i7a$1@dont-email.me> |
| In reply to | #101448 |
On 11/01/17 19:50, supercat@casperkitty.com wrote: > On Wednesday, January 11, 2017 at 12:25:52 PM UTC-6, Richard Heathfield wrote: >> On 11/01/17 16:16, supercat wrote: >>> 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". > > How many str* functions do you use? Do you use strcat or strncat? How > about strtok? There are 17 str* functions in C90's string.h. Of those, I can find no occurrences of strcoll or strxfrm in my code base. All the others are used at least once, but some (eg strn*) are used very sparingly indeed. I am not a fan of strn*, but very occasionally it is the Right Thing. <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]
| From | jadill33@gmail.com |
|---|---|
| Date | 2017-01-11 12:26 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <56ee581b-616d-43d9-9b55-d13a5a2926b3@googlegroups.com> |
| In reply to | #101446 |
On Wednesday, January 11, 2017 at 1:25:52 PM UTC-5, Richard Heathfield wrote:
> On 11/01/17 16:16, s...@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?
I'd argue the case that if streq were standardized back when the standard
library was created, it would make string equality comparisons slightly
more readable. For a single string equality comparison, there's not much
gain (but in my opinion still tangible), but if you're building compound expression statements with multiple string equality checks, readability
of streq goes up.
A slightly more compelling argument for streq is that while strcmp
is nicely associated with sorting and bsearch, I'd argue that for
linear searches, a streq function represents the semantics better.
But, only quicksort and bsearch were standardized.
Here's an example from my array interface.
void gc_array_insert_sorted( struct c_array* array,
void* object,
int (*cmp_fn)( const void*, const void* ),
size_t sz );
void* gc_array_search( struct c_array* array,
const void* property,
bool (*pred_fn)( const void*, const void* ),
size_t sz );
You could still use an 'int' return argument instead of a 'bool' in
pred_fn for searching, but it's not as clean, at least for simple
linear searching of containers.
My point is that imo there is enough motivation to at least justify
creating a 'streq' concept if it simplifies the syntax expressing
the semantics of what you're trying to communicate in reading the code,
even for simple 'strcmp( s1, s2 ) == 0' (in that I know I'd use streq
over strcmp for string equality, especially if it was standarized).
I don't think there's enough of a case to argue for standardizing such
a function now though ... not enough to spend any serious effort arguing
about it. Still, the use case is very prevalent in source code
(represented as 'strcmp( s1, s2 ) == 0'), but without the initial push
to include it in the original standard (compounded by the lack of bool
in C89), the established de-facto method for performing string equality
checks will always be strcmp.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-11 20:44 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o565ce$jie$1@dont-email.me> |
| In reply to | #101453 |
On 11/01/17 20:26, jadill33@gmail.com wrote: > On Wednesday, January 11, 2017 at 1:25:52 PM UTC-5, Richard Heathfield wrote: >> On 11/01/17 16:16, s...@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? > > I'd argue the case that if streq were standardized back when the standard > library was created, it would make string equality comparisons slightly > more readable. Yes, I'd accept that --- but it wasn't. To introduce streq /now/ would make it marginally harder to read code (because we'd double-take at every strcmp). It wouldn't be a big problem, of course, but it would be a (minor) cost of introducing streq. Add that to the major cost of getting it through ISO, and I'd say that the game isn't worth the candle. -- 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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-09 09:03 -0800 |
| Message-ID | <lno9zgqi6q.fsf@kst-u.example.com> |
| In reply to | #101334 |
Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I don't use 0 for success because I cannot use in ifs
>
> if (F())
> {
> //success
> }
if (F() == 0) {
// success
}
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-08 11:40 -0800 |
| Message-ID | <163fde45-c695-4b62-994f-010064dfbcc3@googlegroups.com> |
| In reply to | #101294 |
On Sunday, January 8, 2017 at 8:34:30 AM UTC-6, Thiago Adams wrote: > I think the C standard should add a type and values for > common errors to void conversions between types/values. The use of various conventions for error codes results from the fact that some functions only need to report one kind of success but multiple kinds of failure, some need to report one kind of failure but multiple kinds of success, and some need to report multiple kinds of success and multiple kinds of failure. Since there is only one way for a function to return zero but there are multiple ways for it to return non-zero, that means that there are sometimes advantages to having zero mean success, but there are sometimes advantages to having 0 mean failure. I do think there could be use for standard latching error-reporting flags that could be more useful than errno for handling pass-fail logic. At present, many functions are guaranteed to set errno if they fail, but may arbitrarily modify it or not on success, making it relatively unhelpful for that purpose. A standardized error flag could allow some substantial optimization opportunities which would otherwise be unavailable. If a loop aborts when it encounters an error condition, that will make the behavior of later iterations dependent upon earlier ones. If instead there were an intrinsic that could be used to let a compiler skip a loop *at its convenience* if an error occurred, such a directive could break the dependency and allow different iterations to be performed in parallel without requiring them to waste time on computations which have been found to be useless.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web