> Perhaps, but it breaks the spirit of all these standards (that you
> can have either a library or kernel implementation).
maybe... I don't know enough about either standard to comment.
I do understand what you are saying about syscall/libc transparency
and for the most part agree - but I do like getting EFAULT instead of
a coredump in some applications, mainly because I can write code to
recover from this more elegantly that a coredump.
And before you say, I shouldn't get EFAULT, wrong. I do get them.
Oh hang, no I don't, I forgot. My code if perfect. Silly me thinking
I might code the odd error...
> > I've got code that pretty much expects EFAULT to work one way or
> > another. Arguably, the code is broken, but so far it works on
> > most OSs I've tried it one.
>
> It IS broken; there is really no excuse for it (you're redirecting
> through an invalid pointer, and relying on the internals of libc.)
Maybe. I'd like failure modes to be documented.
I posted something earlier about reading small files into partially
PROT_NONE buffers and the considerable inconsistencies differnet OSs
and released of linux can show.
> Someone just pointed out that it really cannot -- you can hack to
> make it raise the signal, but the signal context will be all wrong.
OK... then if this is necessary for some people, it should be
per-process with a sysctl setting the value for newly created
processes (0 - EFAULT, 1 - segfault, 2 - from parent, etc) with a
default to EFAULT.
This way, nothing that works breaks, and people who are clueful can
twiddle knobs and have core-dumps all over the place.
Yes, lots of applications use crappy pointers, gcc even did at one
point, when Intel had the printk code for the fixup, you could grep
your logs and find nasty such app.
Alpha still has this. IMO, all archs should have this, defaulting to
off, but being able to be turned on via sysctl.
This way, people can turn it on, run regressions tests and check
their logs for evils. The same applics toa segfault_not_EFAULT
sysctl.
-cw
(yes, I like sysctl)
-
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