From: Pedro Alves <pedro_alves@portugalmail.pt>
To: gdb@sourceware.org
Subject: Re: Small remote file transfer protocol adition
Date: Tue, 29 Jan 2008 15:21:00 -0000 [thread overview]
Message-ID: <479F4456.1090306@portugalmail.pt> (raw)
In-Reply-To: <479EAB6F.8040505@portugalmail.pt>
>On Tue, Jan 29, 2008 at 04:28:31AM +0000, Pedro Alves wrote:
>> To be able support this, this proposal adds an optional field
>> to the reply packet:
>>
>> F$(retcode),$(remote_error),$(native_error);
>
>I don't like designing an interface that is going to have to show hex
>numbers to the user. They'd have to figure out that it was a target
>error number and look it up themselves.
We could state it clearly in the error message:
With native error:
Unkown remote I/O error. Target error was: 0xc0454054
Remote I/O error: $(strerror(host_error)). Target error was: 161
Without:
Unkown remote I/O error.
Remote I/O error: $(strerror(host_error)).
> Despite the localization
>issues involved, do you think it might be better to add an error
>string if you need the extra detail? We could put it in the
>attachment field.
I missed that field. I guess it would work too.
>Could you give me an example of a useful error code which does not map
>to one of the POSIX errors?
Most regular ones map correctly, but you lose detail.
Win32 codes are more finer grained then posix error codes.
E.g. for my preliminary patch:
case ERROR_ACCESS_DENIED:
case ERROR_SHARING_VIOLATION:
return FILEIO_EACCES;
case ERROR_FILENAME_EXCED_RANGE:
case ERROR_INVALID_DATA:
case ERROR_INVALID_PARAMETER:
case ERROR_NEGATIVE_SEEK:
return FILEIO_EINVAL;
Then, there's always the unexpected error that happens once,
and is hard to reproduce. winerr.h from w32api defines around
1500 error codes. Granted, most aren't file io related, but
I'm sure I'll miss one or two in the mapping. I'd rater see it
in the error message when it happens.
Currently, in this situation we get:
Unknown remote I/O error.
Not helpful, scarry, and these missing mappings tend to
not get fixed.
Would a patch that implements support for the attachment
field in an error reply be accepted, in principle?
I'll give it a try.
--
Pedro Alves
next prev parent reply other threads:[~2008-01-29 15:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 4:29 Pedro Alves
2008-01-29 13:58 ` Daniel Jacobowitz
2008-01-29 15:21 ` Pedro Alves [this message]
2008-01-29 16:43 ` Daniel Jacobowitz
2008-01-29 17:52 ` Pedro Alves
2008-01-31 14:56 ` Daniel Jacobowitz
2008-01-31 18:15 ` Pedro Alves
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=479F4456.1090306@portugalmail.pt \
--to=pedro_alves@portugalmail.pt \
--cc=gdb@sourceware.org \
/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