From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5747 invoked by alias); 29 Jan 2008 15:21:30 -0000 Received: (qmail 5733 invoked by uid 22791); 29 Jan 2008 15:21:28 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 15:21:02 +0000 Received: by fk-out-0910.google.com with SMTP id 26so1679818fkx.8 for ; Tue, 29 Jan 2008 07:20:59 -0800 (PST) Received: by 10.78.183.8 with SMTP id g8mr9551129huf.42.1201620058668; Tue, 29 Jan 2008 07:20:58 -0800 (PST) Received: from ?192.168.0.101? ( [85.240.255.200]) by mx.google.com with ESMTPS id i6sm1908523gve.5.2008.01.29.07.20.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jan 2008 07:20:57 -0800 (PST) Message-ID: <479F4456.1090306@portugalmail.pt> Date: Tue, 29 Jan 2008 15:21:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Small remote file transfer protocol adition References: <479EAB6F.8040505@portugalmail.pt> In-Reply-To: <479EAB6F.8040505@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00310.txt.bz2 >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