> On Sep 20, 2016, at 2:19 PM, Greg Clayton <gclay...@apple.com> wrote: > > Again, strlen is a stupid example as it is well documented. All of llvm and > clang are not.
IMO that is: 1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM being not document I just have to point you to one example where it is). 2) Not productive or constructive attitude. I’m not sure where you go with that… — Mehdi >> On Sep 20, 2016, at 1:59 PM, Zachary Turner <ztur...@google.com> wrote: >> >> >> >> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton <gclay...@apple.com> wrote: >> >>> 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; >> >> I find it hard to believe that you are arguing that you cannot EVER know >> ANYTHING about the state of your program. :-/ >> >> This is like arguing that you should run a full heap integrity check every >> time you perform a memory write, just to be sure you aren't about to crash. >> >> If you make a std::vector<>, do we need to verify that its internal pointer >> is not null before we write to it? Probably not, right? Why not? Because >> it has a specification of how it works, and it is documented that you can >> construct one, you can use it. >> >> It's ok to document how functions work, and it is ok to assume that >> functions work the way they claim to work. > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
