From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Thu, 3 Jun 2004 15:58:41 +0100 [thread overview]
Message-ID: <ac5fe54b252d0d8d4c466463f2ee85d4@terzarima.net> (raw)
In-Reply-To: <62e4022c76189277635e462989273aaf@vitanuova.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
i think i might have used strstr.
ok, i suppose you might have a file with 'does not exist' in its name,
but i can't say i lose much sleep over it. could use strqstr to look outside quotes i suppose.
also, in
term% ls /sys/src/cm/db
ls: /sys/src/cm/db: '/sys/src/cm/db' does not exist
if it were
ls: /sys/src/cm/db: file does not exist: '/sys/src/cm/db'
i'd find it a little odd to read, myself, although again i can't get too worked up about it.
in APE's case i suspect i'd settle for putting the most common error
strings at the front, on the grounds that most applications stop processing
once an error occurs anyhow, except for access/open/exec/stat when
used to search for something. (so do the check for `does not exist' or
`no permission' early.)
is this worry the result of having profiled something important?
i vaguely remember from my time fighting it that gcc's cpp
causes the computer to wade through
pages of filth to get anywhere when doing the search lists for #include
but there's much more to slow you down in that thing.
perhaps like Linus's scheduler someone has finally done the decent thing?
anyhow: IS there a real cause to worry about APE's string -> errno
translation speed based on (say) a profile of an application, or is
it conjecture?
[-- Attachment #2: Type: message/rfc822, Size: 8170 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 615 bytes --]
> i assume because it reads better, in english anyway
this is a pity.
i think something like:
file does not exist: '/usr/rog/dvfgfdds'
is just as readable, and adheres to the usual convention
for cascading of error messages (most to least recent;
truncation can occur at the end if necessary).
it is sometimes necessary to have a program distinguish
between error messages, and the way i've seen some
programs deal with the current convention:
n = sizeof " does not exist" - 1;
if(strlen(e) > n && strcmp(strlen(e)-n, " does not exist")){
/* file does not exist */
}
is just wrong.
[-- Attachment #2.1.2: Type: message/rfc822, Size: 5122 bytes --]
[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 53 bytes --]
i assume because it reads better, in english anyway
[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 2587 bytes --]
From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Thu, 3 Jun 2004 15:01:47 +0100
Message-ID: <4a8f5dee0a8d8ba7be23785692dd2317@vitanuova.com>
> you return the %r chunk and then hash it into an associative array of translated messages, indexed by hash.
no you couldn't, 'cos the kernel adds a filename for some error messages.
was there a good reason why the filename was put in front of the error
message rather than vice versa? it seems odd - it means you have to
parse the error message, rather than just doing a strncmp, and you
don't have to worry too much about the filename being truncated at the
end.
next prev parent reply other threads:[~2004-06-03 14:58 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-01 11:09 [9fans] GNU Make lucio
2004-06-01 16:37 ` boyd, rounin
2004-06-01 21:03 ` ron minnich
2004-06-01 21:09 ` boyd, rounin
2004-06-01 21:43 ` Russ Cox
2004-06-01 21:49 ` ron minnich
2004-06-01 22:03 ` Russ Cox
2004-06-01 22:08 ` boyd, rounin
2004-06-02 5:34 ` lucio
2004-06-02 7:36 ` Charles Forsyth
2004-06-02 9:07 ` John Murdie
2004-06-02 9:39 ` Charles Forsyth
2004-06-02 16:12 ` ron minnich
2004-06-02 16:24 ` lucio
2004-06-02 16:54 ` ron minnich
2004-06-02 16:56 ` boyd, rounin
2004-06-03 6:41 ` lucio
2004-06-03 8:49 ` Charles Forsyth
2004-06-03 9:16 ` boyd, rounin
2004-06-03 9:50 ` Error reporting (Was: [9fans] GNU Make) lucio
2004-06-03 14:01 ` rog
2004-06-03 13:54 ` Charles Forsyth
2004-06-03 14:19 ` rog
2004-06-03 14:18 ` boyd, rounin
2004-06-03 14:31 ` lucio
2004-06-03 14:33 ` rog
2004-06-03 14:58 ` Charles Forsyth [this message]
2004-06-03 15:13 ` lucio
2004-06-03 15:17 ` rog
2004-06-03 16:12 ` C H Forsyth
2004-06-03 16:18 ` rog
2004-06-03 16:18 ` Charles Forsyth
2004-06-03 16:38 ` rog
2004-06-03 16:56 ` C H Forsyth
2004-06-03 17:03 ` rog
2004-06-03 17:15 ` C H Forsyth
2004-06-03 17:25 ` rog
2004-06-03 19:10 ` boyd, rounin
2004-06-03 19:08 ` boyd, rounin
2004-06-03 19:35 ` rog
2004-06-03 19:46 ` boyd, rounin
2004-06-03 20:06 ` rog
2004-06-03 22:09 ` Charles Forsyth
2004-06-04 1:05 ` Bruce Ellis
2004-06-04 1:56 ` Scott Schwartz
2004-06-04 2:10 ` Bruce Ellis
2004-06-04 2:46 ` Russ Cox
2004-06-04 8:08 ` Charles Forsyth
[not found] ` <013301c449d2$95929d30$637f7d50@SOMA>
2004-06-04 12:16 ` Bruce Ellis
2004-06-08 15:17 ` rog
2004-06-03 14:06 ` boyd, rounin
2004-06-03 14:21 ` rog
2004-06-03 10:31 ` [9fans] GNU Make lucio
2004-06-03 14:53 ` Rob Pike
2004-06-03 15:01 ` boyd, rounin
2004-06-03 15:04 ` lucio
2004-06-03 15:16 ` Rob Pike
2004-06-03 15:33 ` rog
2004-06-03 15:40 ` boyd, rounin
2004-06-03 15:58 ` lucio
2004-06-03 15:40 ` lucio
2004-06-03 15:20 ` [9fans] internationalised error messages boyd, rounin
2004-06-02 21:30 ` [9fans] GNU Make boyd, rounin
2004-06-02 8:54 ` Richard Miller
2004-06-02 9:17 ` lucio
2004-06-02 9:54 ` Charles Forsyth
2004-06-02 16:15 ` ron minnich
2004-06-02 17:00 ` Steve Simon
2004-06-03 5:14 ` lucio
2004-06-02 14:00 ` ron minnich
2004-06-02 14:36 ` C H Forsyth
2004-06-02 14:33 ` Charles Forsyth
2004-06-02 15:24 ` Charles Forsyth
2004-06-02 15:56 ` lucio
2004-06-02 16:11 ` lucio
2004-06-02 19:28 ` Joel Salomon
2004-06-03 4:43 ` [9fans] troff and 4.4BSD man pages Lyndon Nerenberg
2004-06-03 5:54 ` Taj Khattra
2004-06-03 8:26 ` boyd, rounin
2004-06-07 8:55 ` Douglas A. Gwyn
2004-06-07 13:19 ` Jon Snader
[not found] ` <z4udnTOQMJVTdlndRVn-jg@comcast.com>
2004-06-10 10:58 ` Aharon Robbins
2004-06-10 12:40 ` rog
2004-06-10 13:24 ` Douglas A. Gwyn
2004-06-03 10:13 ` Bruce Ellis
2004-06-03 10:17 ` boyd, rounin
2004-06-03 10:27 ` lucio
2004-06-03 10:29 ` Bruce Ellis
2004-06-03 10:26 ` boyd, rounin
2004-06-03 11:18 ` Bruce Ellis
2004-06-03 1:57 ` [9fans] GNU Make a
2004-06-03 3:31 ` Kenji Okamoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac5fe54b252d0d8d4c466463f2ee85d4@terzarima.net \
--to=forsyth@terzarima.net \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).