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 | 20 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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-11 21:05 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o566k2$nrp$1@dont-email.me> |
| In reply to | #101464 |
On 11/01/17 21:01, Keith Thompson wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > [...] >> #define streq(s,t) (!!strcmp(s,t)) > > Was the logical error deliberate? It appears not. (Actually, it appears not not, but it was intended to appear not.) -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-11 21:08 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o566pk$nok$1@dont-email.me> |
| In reply to | #101464 |
On 11/01/2017 21:01, Keith Thompson wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > [...] >> #define streq(s,t) (!!strcmp(s,t)) > > Was the logical error deliberate? Apparently not. It just reinforces my point that strcmp by itself is unintuitive. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-01-11 21:38 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <87o9zdtgzo.fsf@gmail.com> |
| In reply to | #101466 |
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. I must say, I find Matlab's way round much more intuitive, but its never crossed my mind to whine about it. You learn the idiosyncracy and go about your day.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-11 21:58 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o569mn$3h7$1@dont-email.me> |
| In reply to | #101467 |
On 11/01/2017 21:38, Gareth Owen 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. > > I must say, I find Matlab's way round much more intuitive, but its never > crossed my mind to whine about it. You learn the idiosyncracy and go > about your day. I'm not really whining about strcmp. (Even though I've forgotten the '== 0' bit a few times and wasted time finding the bug. There are bigger issues to moan about in the language.) It's more people trying to make out that everything is fine, that strcmp()==0 or !strcmp() is just as clear as streq() might be (and insinuating that if /I/ don't find it obvious, I probably don't understand C). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-12 12:11 +0100 |
| Subject | Re: standard error codes |
| Message-ID | <o57o66$urn$1@dont-email.me> |
| In reply to | #101467 |
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". > 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. That sounds like a bad idea. They should have picked a different name for different functionality. > > I must say, I find Matlab's way round much more intuitive, but its never > crossed my mind to whine about it. You learn the idiosyncracy and go > about your day. > Exactly.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-12 09:28 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <lnwpe0nq6n.fsf@kst-u.example.com> |
| In reply to | #101509 |
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.
(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.)
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-12 18:06 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o58gg3$d6i$1@dont-email.me> |
| In reply to | #101531 |
On 12/01/17 17:28, Keith Thompson 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. Actually, I agree with David here: strdiff would be a better name, for the same reason that diff(1) is well-named (see below). > 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. Yes. Although strdiff would be a better name, strcmp will do. > (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.) diff returns 0 if the diff is 0. What's to be bothered about? -- 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-12 11:39 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <lnshoonk3c.fsf@kst-u.example.com> |
| In reply to | #101535 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/01/17 17:28, Keith Thompson 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.
>
> Actually, I agree with David here: strdiff would be a better name, for
> the same reason that diff(1) is well-named (see below).
I still disagree, for the reasons I've stated, but it's not a big deal.
>> 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.
>
> Yes. Although strdiff would be a better name, strcmp will do.
>
>> (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.)
>
> diff returns 0 if the diff is 0. What's to be bothered about?
The status returned by a command is not a count, it's a success/failure
indication, with an opportunity to distinguish among different kinds of
failures (at least on Unix-like systems, where EXIT_SUCCESS==0 and any
non-zero status (modulo 256) denotes failure).
The shell's "if" statement treats a successful status of 0 as
a true condition. One might naively assume that:
if diff file1 file2 ; then
echo yes
else
echo no
fi
would print "yes" if the files differ. (csh/tcsh use different syntax,
but the same idea holds.) And typically the output of the diff command
is of more interest than its status.
Again, this is not a big deal, just a small thing you have to learn
if you want to use the diff command. It's far more important to
be aware that the command returns 0 (success) if the files are
the same, 1 (generic failure) if they differ, and 2 if there's
an error, than to worry about whether that makes sense given the
command's name.
The fact that 0 and 1 sometimes mean false and true, respectively, and
sometimes mean success and failure, can be confusing. There are good
reasons the convention is the way it is, and even if there weren't we'd
still just have to deal with it.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-12 19:50 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o58miv$4ud$1@dont-email.me> |
| In reply to | #101541 |
On 12/01/17 19:39, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: <snip> >> Actually, I agree with David here: strdiff would be a better name, for >> the same reason that diff(1) is well-named (see below). > > I still disagree, for the reasons I've stated, but it's not a big deal. Agreed (that it's not a big deal). >>> 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. >> >> Yes. Although strdiff would be a better name, strcmp will do. >> >>> (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.) >> >> diff returns 0 if the diff is 0. What's to be bothered about? > > The status returned by a command is not a count, it's a success/failure > indication, with an opportunity to distinguish among different kinds of > failures (at least on Unix-like systems, where EXIT_SUCCESS==0 and any > non-zero status (modulo 256) denotes failure). Sure. But ALMOST without exception, when I call diff, I'm using it to determine whether a difference exists between two files that I expect to be the same. Thus, a difference would count as failure. No difference would count as success, and by a happy coincidence 0 (success) is what is returned when there is no difference between the two files. This is a perfectly reasonable way to justify the choices that the diff writers made... > The shell's "if" statement treats a successful status of 0 as > a true condition. One might naively assume that: > > if diff file1 file2 ; then > echo yes > else > echo no > fi > > would print "yes" if the files differ. ...and that is an equally reasonable contrary view. :-) > (csh/tcsh use different syntax, > but the same idea holds.) And typically the output of the diff command > is of more interest than its status. For me at least, typically the /lack/ of output of the diff command is what I like to see. (But that's only another way of saying the same thing.) Anyway... back to C? -- 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-12 13:03 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <ln7f60ng7q.fsf@kst-u.example.com> |
| In reply to | #101544 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Sure. But ALMOST without exception, when I call diff, I'm using it to
> determine whether a difference exists between two files that I expect to
> be the same. Thus, a difference would count as failure. No difference
> would count as success, and by a happy coincidence 0 (success) is what
> is returned when there is no difference between the two files. This is a
> perfectly reasonable way to justify the choices that the diff writers
> made...
OK. I usually want to see how two files (often two versions of the same
file) differ, and I usually expect them to differ. If all I care about
is whether they differ or not, "cmp" is likely to be faster (perhaps not
significantly so).
[...]
> Anyway... back to C?
By all means.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-12 21:13 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o58rf2$o47$1@dont-email.me> |
| In reply to | #101554 |
On 12/01/17 21:03, Keith Thompson wrote: <snip> > > OK. I usually want to see how two files (often two versions of the same > file) differ, and I usually expect them to differ. If all I care about > is whether they differ or not, "cmp" is likely to be faster (perhaps not > significantly so). I didn't know about cmp. Thanks. -- 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 | <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2017-01-12 20:00 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <8vvlkd-4es.ln1@wilbur.25thandClement.com> |
| In reply to | #101555 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 12/01/17 21:03, Keith Thompson wrote: > <snip> >> >> OK. I usually want to see how two files (often two versions of the same >> file) differ, and I usually expect them to differ. If all I care about >> is whether they differ or not, "cmp" is likely to be faster (perhaps not >> significantly so). > > I didn't know about cmp. Thanks. You can download the POSIX standard for free from https://www2.opengroup.org/ogsys/catalog/c165 The free version is an off-line, frames-based HTML document. If you select the Shell & Utilities volume, then the Utilities section, you'll get a very helpful list of all standard shell utilities in the bottom left navigtion frame. A few minutes browsing the list is the equivalent of years of haphazard introductions on the command-line. The POSIX C interface documentation is similarly useful, and apropos comp.lang.c often contains information and analysis about compliance with the C standard. Occassionally bugs or ambiguities in the C standard come out when discussing proposals and errata. See http://austingroupbugs.net/view_all_bug_page.php I've admonished countless engineers at my company to keep a copy of both the ISO C standard and the POSIX standard on their computer desktop. I don't think a single one has ever listened to me. *sigh* It's especially frustrating because both standards--their content, presentation, and style--are exceptionally easy to read and understand, yet retain a tremendously high signal-to-noise ratio.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 01:56 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <c0c110f0-c1f5-4eb6-91ea-36e013168a41@googlegroups.com> |
| In reply to | #101577 |
On Friday, January 13, 2017 at 4:15:12 AM UTC, wil...@wilbur.25thandclement.com wrote: > > I've admonished countless engineers at my company to keep a copy of both the > ISO C standard and the POSIX standard on their computer desktop. I don't > think a single one has ever listened to me. *sigh* It's especially > frustrating because both standards--their content, presentation, and > style--are exceptionally easy to read and understand, yet retain a > tremendously high signal-to-noise ratio. > standard functions not behaving as I think they ought just isn't one of the C programming problems I face. In C++ yes, the language is so big and the syntax so involved and unintuitive that often you have to look up constructs.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-13 12:54 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o5aiii$kgm$1@dont-email.me> |
| In reply to | #101577 |
On 13/01/17 04:00, william@wilbur.25thandClement.com wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: >> On 12/01/17 21:03, Keith Thompson wrote: >> <snip> >>> >>> OK. I usually want to see how two files (often two versions of the same >>> file) differ, and I usually expect them to differ. If all I care about >>> is whether they differ or not, "cmp" is likely to be faster (perhaps not >>> significantly so). >> >> I didn't know about cmp. Thanks. > > You can download the POSIX standard for free from I already have a copy of, admittedly, a draft standard, and cmp is mentioned. I also have books on Unix and Linux coming out of my ears and spilling out of my bookshelves, and cmp is doubtless mentioned in many of them. I have man pages and info pages on cmp. I probably have shell scripts on my system that use cmp. I may even have the source code to cmp. Nevertheless, I didn't know about cmp. POSIX is quite big. -- 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-13 09:35 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <lnh952n9r5.fsf@kst-u.example.com> |
| In reply to | #101603 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 13/01/17 04:00, william@wilbur.25thandClement.com wrote:
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>> On 12/01/17 21:03, Keith Thompson wrote:
>>> <snip>
>>>>
>>>> OK. I usually want to see how two files (often two versions of the same
>>>> file) differ, and I usually expect them to differ. If all I care about
>>>> is whether they differ or not, "cmp" is likely to be faster (perhaps not
>>>> significantly so).
>>>
>>> I didn't know about cmp. Thanks.
>>
>> You can download the POSIX standard for free from
>
> I already have a copy of, admittedly, a draft standard, and cmp is
> mentioned. I also have books on Unix and Linux coming out of my ears and
> spilling out of my bookshelves, and cmp is doubtless mentioned in many
> of them. I have man pages and info pages on cmp. I probably have shell
> scripts on my system that use cmp. I may even have the source code to cmp.
>
> Nevertheless, I didn't know about cmp.
>
> POSIX is quite big.
Speaking of info pages, "info coreutils" (if you have it installed) may
also bring some useful commands you weren't aware of to your attention.
For example I've found "tac" (cat backwards) to be surprisingly useful.
And back to C.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-13 17:38 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o5b37p$rbo$1@dont-email.me> |
| In reply to | #101623 |
On 13/01/17 17:35, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: <snip> >> >> I already have a copy of, admittedly, a draft standard, and cmp is >> mentioned. I also have books on Unix and Linux coming out of my ears and >> spilling out of my bookshelves, and cmp is doubtless mentioned in many >> of them. I have man pages and info pages on cmp. I probably have shell >> scripts on my system that use cmp. I may even have the source code to cmp. >> >> Nevertheless, I didn't know about cmp. >> >> POSIX is quite big. > > Speaking of info pages, "info coreutils" (if you have it installed) may > also bring some useful commands you weren't aware of to your attention. > For example I've found "tac" (cat backwards) to be surprisingly useful. Does it have one of those things for getting stones out of horses' hooves? -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-13 13:06 -0500 |
| Subject | Re: standard error codes |
| Message-ID | <o5b4rf$bh8$2@dont-email.me> |
| In reply to | #101624 |
On 01/13/2017 12:38 PM, Richard Heathfield wrote:
> On 13/01/17 17:35, Keith Thompson wrote:
...
>> Speaking of info pages, "info coreutils" (if you have it installed) may
>> also bring some useful commands you weren't aware of to your attention.
>> For example I've found "tac" (cat backwards) to be surprisingly useful.
>
> Does it have one of those things for getting stones out of horses' hooves?
grep -v stone horses_hoof
:-)
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-18 12:00 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <587f57a4.3244578@news.xs4all.nl> |
| In reply to | #101624 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 13/01/17 17:35, Keith Thompson wrote: > > Richard Heathfield <rjh@cpax.org.uk> writes: > >> POSIX is quite big. > > > > Speaking of info pages, "info coreutils" (if you have it installed) may > > also bring some useful commands you weren't aware of to your attention. > > For example I've found "tac" (cat backwards) to be surprisingly useful. > > Does it have one of those things for getting stones out of horses' hooves? I don't know, but I strongly suspect that somewhere in there there is an adjustable device for winning ontological arguments. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-18 12:13 +0000 |
| Subject | Re: standard error codes |
| Message-ID | <o5nm2f$5bd$1@dont-email.me> |
| In reply to | #102111 |
On 18/01/17 12:00, Richard Bos wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > >> On 13/01/17 17:35, Keith Thompson wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: > >>>> POSIX is quite big. >>> >>> Speaking of info pages, "info coreutils" (if you have it installed) may >>> also bring some useful commands you weren't aware of to your attention. >>> For example I've found "tac" (cat backwards) to be surprisingly useful. >> >> Does it have one of those things for getting stones out of horses' hooves? > > I don't know, but I strongly suspect that somewhere in there there is an > adjustable device for winning ontological arguments. Thanks, Shawn. I'll bear it in mind the next time I have an ontological argument. Hmmm. Actually, I'll take it now. Which one is it, that little fiddly one next to the corkscrew? -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-12 16:43 -0800 |
| Subject | Re: standard error codes |
| Message-ID | <c7df1c42-c324-4b80-ba79-76497248a0da@googlegroups.com> |
| In reply to | #101535 |
On Thursday, January 12, 2017 at 6:06:32 PM UTC, Richard Heathfield wrote: > > Yes. Although strdiff would be a better name, strcmp will do. > The memcmp either does something a bit different, or is called memdiff. But I would expect memdiff() to calculate the full difference between two blocks of memory, not just the difference in the first different byte.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web