Again, strlen is a stupid example as it is well documented. All of llvm and
clang are not.
> 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:
> if (!p)
> 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.
> 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