> 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…


>> 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

Reply via email to