> Will they really go for that ?
>
> I mean, the explicit "NULL exception" is one thing,
> but claiming that the
> function may not crash for any random pointer passed
> in, but return EINVAL
> instead, forces either a system call (to error out on
> copyin() failure) or
> a horrid "check against all previously opened DIR*"
> userland hack.
No, "may" return EINVAL doesn't mean "must". It just means allowed
to do something other than SIGSEGV kablooey.
In most cases, I'd wholeheartedly agree that checking for NULL pointers is bad.
But in this particular case, a certain perverse love of one-liners has me
wishing I could fetch both DIR * and fd and check them, all at once, like:
int fd;
DIR *dp;
if ((fd=dirfd(dp=opendir("/my/dir"))) == -1) {
/*fail*/
}
Of course, since other platforms may choose not to make dirfd() NULL-safe,
that wouldn't be portable (and no doubt someone will complain that it's too
obfuscated anyway). I still think that the principle of _not_ catching NULL
args applies somewhat less when the only place the arg should have come from
is the return value of a single library function. But if nobody here would buy
that,
I very much doubt I could sway the whole Austin Group bunch, just so that that
particular convienience could be portable. :-(
Maybe I ought to take up APL or LISP, as a harmless place for such urges. :-/
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
