Sigh. I should have put a smiley there. The serious point I was making
was that I can't determine what pointers the application will pass.
> > > Once again: if you're relying on EFAULT rather than SIGSEGV, your code
> > > is broken, as you're relying on details of the libc/kernel interface.
> > > I would argue that *IS* a bug in your "bug-free" library.
> >
> > I'm relying on what I've seen written in man pages for all varieties
> > of Unix I've had access to.
>
> Yes, it says that it's a PERMITTED return value, which is
> fundamentally different from GUARANTEED.
>
> > This abstract libc/kernel interface you refer to is an abstraction
> > you've invented. It's not Unix practice. Unix practice is to return
> > EFAULT on system calls. System calls are open(2), read(2), write(2)
> > and similar.
>
> I didn't invent it. It has been in every single Unix spec I've ever
> read, and it's very explicit.
I'm staring at the read(2) man page for Solaris 2.5 and it talks about
EFAULT. I don't see where it implies that EFAULT is optional.
> > > If you want to trap errors, you either have to sanitize the input, or
> > > trap SIGSEGV.
> >
> > I can't sanitise the input: I don't know what pointer the application
> > will pass. Trapping SEGV is a performance bugger: I have to install a
> > signal handler before every pseudo-syscall and restore it afterwards
> > (my library can't steal signals).
You haven't responded to this part. Wrapping *every* call to read(2)
with a signal/setjmp save/restore is a performance killer.
Can you actually be serious that an application/library that tries to
trap bad addresses has to put up with this?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html