> On Sep 20, 2016, at 1:45 PM, Zachary Turner <ztur...@google.com> wrote:
>
> I do agree that asserts are sometimes used improperly. But who's to say that
> the bug was the assert, and not the surrounding code? For example, consider
> this code:
>
> assert(p);
> int x = *p;
Should be written as:
assert(p);
if (!p)
do_something_correct();
else
int x = *p;
>
> Should this assert also not be here in library code? I mean it's obvious
> that the program is about to crash if p is invalid. Asserts should mean
> "you're about to invoke undefined behavior", and a crash is *better* than
> undefined behavior. It surfaces the problem so that you can't let it slip
> under the radar, and it also alerts you to the point that the UB is invoked,
> rather than later.
>
> What about this assert?
>
> assert(ptr);
> int x = strlen(ptr);
>
> Surely that assert is ok right? Do we need to check whether ptr is valid
> EVERY SINGLE TIME we invoke strlen, or any other function for that matter?
> The code would be a disastrous mess.
Again, check before you call if this is in a shared library! What is so hard
about that? It is called software that doesn't crash.
assert(ptr)
int x = ptr ? strlen(ptr) : 0;
>
> If you think you've found an improper assert, the thing to do is raise it on
> the proper mailing list and present your case of why you think it's an
> improper assert. asserting is not inherently wrong, but like anything, you
> have to use it right.
The code to strlen() is well documented. All code in llvm and clang is not.
Asserts fire off all the time for reasons the original author and others close
to the code know about, but when the llvm and clang APIs are used by others, we
don't know all of these cases. They aren't documented. The only way to find
them is to crash when you run into them with questionable input. Not acceptable
for a library.
>
> On Tue, Sep 20, 2016 at 1:37 PM Ted Woodward <ted.woodw...@codeaurora.org>
> wrote:
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
> Turner via lldb-dev
> Sent: Tuesday, September 20, 2016 12:47 PM
>
> > This kind of philisophical debate is probably worthy of a separate thread
> > :) That being said, I think asserts are typically used in places where the
> > assert firing means "You're going to crash *anyway*"
>
> This is emphatically NOT the case.
>
> One of the first tasks I was given when I started at Qualcomm was to fix the
> disassembler for Hexagon. It was a mess - it would assert if the disassembly
> tables couldn't identify an opcode. Maybe that's fine for an assembler,
> assert if you can't generate an opcode, but an unidentified opcode should
> print a warning and move on. It's not a fatal error to disassemble data!
>
> There are other instances of this in llvm. I agree with Greg - libraries
> shouldn't assert. Send an error back to the caller, and let the caller
> handle it. A typo in my expression that lldb sends to clang shouldn't crash
> my debug session.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
