<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 18, 2016 at 9:53 AM, Antoine Pitrou via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 17 Dec 2016 21:43:16 -0500<br>
Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I agree that if an API user violates the API of a library, it is<br>
> appropriate for the library to abort with a fatal error.<br><br>
Is it? If you pass an invalid fd to the libc, it replies with a EBADF,<br>
it doesn't crash hard. Most mature libraries have guards against invalid<br>
or inconsistent parameter values, and return error codes to the caller.<br>
<br>
As someone who maintains and uses an LLVM binding to Python (llvmlite),<br>
it's one of the annoyances we have faced: if someone makes a mistake<br>
when calling one of the exposed APIs, that API may crash the process<br>
(while, as Python programmers, they would rather get an exception,<br>
which at least makes it easier to debug and diagnose the issue).<br>
Getting a crude assert-induced crash on a CI machine or a user's<br>
machine is no fun.<br>
<br>
Of course, a C or C++ library cannot guard against everything,<br>
especially not against invalid pointers or corrupted memory.  But large<br>
classes of user errors may be better served by actually returning an<br>
error code rather than failing on an assert.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br></div></div>