From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 13:26:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD34316A4CE; Thu, 23 Dec 2004 13:26:19 +0000 (GMT) Received: from mx1.originative.co.uk (freebsd.gotadsl.co.uk [81.6.249.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E62D43D2F; Thu, 23 Dec 2004 13:26:17 +0000 (GMT) (envelope-from paul@mx1.originative.co.uk) Received: from localhost (unknown [127.0.0.1]) by mx1.originative.co.uk (Postfix) with ESMTP id C040615596; Thu, 23 Dec 2004 13:26:18 +0000 (GMT) Received: from mx1.originative.co.uk ([127.0.0.1])port 10024) with ESMTP id 85128-03; Thu, 23 Dec 2004 13:26:03 +0000 (GMT) Received: by mx1.originative.co.uk (Postfix, from userid 1000) id BDCEE15639; Thu, 23 Dec 2004 13:26:03 +0000 (GMT) Date: Thu, 23 Dec 2004 13:26:03 +0000 From: Paul Richards To: Poul-Henning Kamp Message-ID: <20041223132603.GB786@myrddin.originative.co.uk> References: <20041222010143.GS53357@wantadilla.lemis.com> <8412.1103737516@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8412.1103737516@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: Greg 'groggy' Lehey cc: FreeBSD Architecture Mailing List Subject: Re: Header files with enums instead of defines? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 13:26:19 -0000 On Wed, Dec 22, 2004 at 06:45:16PM +0100, Poul-Henning Kamp wrote: > In message <20041222010143.GS53357@wantadilla.lemis.com>, "Greg 'groggy' Lehey" > writes: > > >Has anybody thought about replacing #defines with enums in header > >files? It would make debugging a whole lot easier. Foe example, I'm > >currently looking at a debug printout which contains: > > I agree with others who have shot this down: compatibility would > not allow us to do something like that. > > But that is not to say that the error reporting mechanism could not > be improved in other ways. > > One of my pet peeves is that comples system calls have no way to > convey additional information about why the return a given > return value like EPERM. > > I would almost advocate adding a char[X] to each thread and a > system call which could retrieve it. Complex system calls like > mount/nmount, ioctl and similar could then stick an explanation > into that string which strerror(3) or err(3) and similar functions > could pull out and give the user. > > There is a heck of a difference between getting: > > fdisk: permission denied > > And > > fdisk: permission denied (partitions overlap) For all projects I've worked on in recent years the first thing I've done is implement an error reporting stack, which basically works in a similar way to exceptions in C++/Java i.e., the error percolates up from where it occurs to a point where something decides to handle it. The error object itself varies from project to project but always includes a message. At whatever point in the stack where something handles the error you can then get a full report as to what each layer in the stack did.