[llvm-dev] LLD status update and performance chart

[Andrew Kelley via llvm-dev]

On Sun, Dec 18, 2016 at 9:53 AM, Antoine Pitrou via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, 17 Dec 2016 21:43:16 -0500
> Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> > I agree that if an API user violates the API of a library, it is
> > appropriate for the library to abort with a fatal error.
>
> Is it? If you pass an invalid fd to the libc, it replies with a EBADF,
> it doesn't crash hard. Most mature libraries have guards against invalid
> or inconsistent parameter values, and return error codes to the caller.
>
> As someone who maintains and uses an LLVM binding to Python (llvmlite),
> it's one of the annoyances we have faced: if someone makes a mistake
> when calling one of the exposed APIs, that API may crash the process
> (while, as Python programmers, they would rather get an exception,
> which at least makes it easier to debug and diagnose the issue).
> Getting a crude assert-induced crash on a CI machine or a user's
> machine is no fun.
>
> Of course, a C or C++ library cannot guard against everything,
> especially not against invalid pointers or corrupted memory.  But large
> classes of user errors may be better served by actually returning an
> error code rather than failing on an assert.


Going above and beyond to avoid crashing for invalid use of the API is
nice, and results in fewer bug reports filed for the library that should be
filed for the upstream application.

However, it's not required for a robust library. The weaker guarantee of
adhering to the API causing no exit paths in the library, is easier to
adhere to, while still letting the upstream application developer create
software that does not crash in the library regardless of the user input.
Trying to go beyond this guarantee is the kind of thing that will make
development less pleasant for Rafael and co, and while nice, is not really
necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161218/21b47cad/attachment.html>