Yes, I know that. But in the context of the science I'm doing, a pure
POSIX-only system is not useful. A Unix system, however, is
useful. And one of my points is that most (all?) existing Unix systems
have EFAULT, and we should avoid diverging from that behaviour.
I have no problem with optional SEGV behaviour. But to abolish EFAULT
is a Bad Thing.
> POSIX/Unix98 say that if the pointer is bogus, the behavour is
> undefined. Solaris goes further to defined this behaviour as
> returning EFAULT.
Solaris and every other Unix I've come across.
> You could write GoochOS and have it defined appropriate behaviour as
> execve("rm",{"-rf","/*"}) if you wanted to.
Bugger that! That's not useful to me. Unix is useful, and being
compatibile with Unix practice is useful.
> I think hpa argument is because POSIX/whatever don't define EFAULT as
> _required_ behaviour, its not correct to write code assuming
> otherwise just because some OSs do otherwise.
But since most (all?) Unix systems have EFAULT, is it wise to deviate
from that? Espectially considering that EFAULT is actually *useful*
and is *used in real life*.
> > 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?
>
> wrapping libc sucks badly. I did this trying to work out how often
> read/write were called and and how often the buffes were page
> aligned, and it noticably slowed down some applications... (results
> were logged, so each syscall became several).
Agreed! Having to save/restore signal handlers for SEGV will kill
performance. Been there, done that.
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