Date: Wed, 22 Dec 2004 12:13:14 -0600 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: FreeBSD Architecture Mailing List <arch@freebsd.org> Subject: Re: Header files with enums instead of defines? Message-ID: <20041222181313.GJ32388@over-yonder.net> In-Reply-To: <8412.1103737516@critter.freebsd.dk> References: <20041222010143.GS53357@wantadilla.lemis.com> <8412.1103737516@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 22, 2004 at 06:45:16PM +0100 I heard the voice of
Poul-Henning Kamp, and lo! it spake thus:
>
> 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.
I do roughly this in the errno-ish facility in my sadly-dormant
libpostal project. My error structure looks like
struct postal_errfoo_t
{
unsigned int postal_errno;
char postal_errstr[POSTAL_ERRSTR_LEN];
};
Of course, I get to mandate that you use postal_errno() and
postal_errstr() to retrieve the data. I use (1<<15) as a flag in the
errno int (at least, until I get a WHOLE lot more error conditions
that I have now) for when there's an extra message to be returned. I
don't think I actually USE the capability anywhere right now, but it's
designed in.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041222181313.GJ32388>