From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: Re: Error reporting capabilities for libxc Date: Tue, 24 Oct 2006 00:05:03 +0100 Message-ID: <20061023230503.GA1817@redhat.com> References: <453D1554.8000202@us.ibm.com> <20061023192753.GG25795@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B205073B@paddington.ad.cl.cam.ac.uk> <20061023205730.GI25795@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B205073C@paddington.ad.cl.cam.ac.uk> <20061023212157.GK25795@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B205073F@paddington.ad.cl.cam.ac.uk> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <3AAA99889D105740BE010EB6D5A5A3B205073F@paddington.ad.cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: Anthony Liguori , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Mon, Oct 23, 2006 at 11:15:21PM +0100, Ian Pratt wrote: > > > Would we be better off returning an error code and a set of > parameters, > > > requiring a call-back into the library to get the string? > > > > That assumes that there is a static mapping between an error code > > and the error description, which there isn't. The error description > > can contain info about actual bits of metadata which were incorrect. > > For example when reporting an invalid ELF architecture, it can tell > > you exactly what ELF arch was found & what was expected. > > That's precisely my point. The various bits of metadata can be > parameters passed back along with the error code. It's possible that > some callers will be able to do things with the metadata that are more > useful than just printing the string. I guess the error parameters could > be returned as a va_list. Many callers would just call back into the > library to get the appropriate error string. Ahh, I mis-read your comment a little. That is certainly one possibility although I'm not entirely a fan of va_list as an API - perhaps either a struct with a handful of generic data fields for returning metadata, or a union switched on the error code would work - it'd be nice to be able to copy all the bits around without needing memory allocation in any of the error handling paths. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|