|
From: Andreas M. <an...@us...> - 2012-11-19 18:57:31
|
Hi,
On Mon, Nov 19, 2012 at 05:37:58PM +0000, lib...@li... wrote:
> Date: Mon, 19 Nov 2012 18:37:47 +0100
> From: Akos Vandra <ax...@gm...>
> I know, that my app is broken, and that is my bad, and I have already
> corrected the error. Nonetheless nothing like that should cause a segfault.
> Actually nothing should cause a segfault, not even improprer usage.
I would actually tend to agree.
Reasoning being that in case of the more usual
single "handle" or "simple pointer" API setup,
there is exactly *one* "unsafe -> safe" layer transition to be made,
namely to check the handle for validity / pointer for non-NULL (well,
actually for valid memory range if you want to be dead certain about it).
And in that case I'd think everybody would not hesitate one bit
to agree that it's always the accepting layer's responsibility
to check for input parameter validity
(also keep in mind the "be liberal in what you accept, conservative in what
you send" motto).
With an API choosing to expose a plain-visible "address of a pointer" interface
instead (does it really need to have that? It certainly complicates matters...
could perhaps be hidden behind an opaque handle instead),
you could then demand the very same thing,
this time plain obviously for *both* of the required indirections of course
("it's not the user's fault for the service to have such a hideously complex API" ;)
So, in my point of view given an address of a pointer, it's absolutely the
responsibility of the accepting layer to validate input.
And of course upon encountering a user-side problem this should then be
logged / indicated as an "error" return, to prevent the case
of having parameter failure getting swallowed silently and thus not noticed.
> This is not embedded code, where a few bytes code length, or a few
> microseconds execution time counts (especially at functions which are
> called only a few times.)
Yup.
Andreas Mohr
|