From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: Suggestion: Improve hypercall Interface to get real return value Date: Wed, 5 Dec 2012 11:54:58 +0000 Message-ID: <50BF3612.9020606@citrix.com> References: <1141524074.6.1354688480672.JavaMail.root@bj-mail05.pku.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 05/12/12 11:05, George Dunlap wrote: > On Wed, Dec 5, 2012 at 6:21 AM, Yanzhang Li > wrote: > > > > Do you think this would be a good modification? > Also, I am curious why the original design didn't do that. Is it a > bug or is it designed that way intentionally? > Any suggestions and comments will be highly appreciated. > > > The reason we just return -1 is because that is the standard practice > for Unix system libraries: to return -1 but set the error value in > "errno". I couldn't tell you why Unix does this, but there's an > advantage to following standard interfaces, because it reduces the > surprise factor, and reduces the amount of information programmers > need to keep in their head. I think returning -1 instead of "the error" allows for simpler code when you do something like this: int func() { FILE *f = fopen(...); if(!f) return -1; while(...) { if (fread(f, ...) < 0) { fclose(f); return -1; } ... if (...) if (fwrite(f, ...) < 0) { fclose(f); return -1; } } fclose(f); return 0; } Now, we don't need extra code to "remember the errno from the failing function". [And I'm assuming here that fclose isn't "interfering" with the errno - if you REALLY need to know for sure what the errno was at fread or fwrite, you still need to "remember errno". (Note that some functions do not return -1 for failure in the above code, but for example NULL, and some function would not be able to return -errno, as that may well be a "valid" return value - so keeping the interface as alike as possible is a good idea) -- Mats > > -George