[lldb-dev] LLDB Evolution - Final Form

[Zachary Turner via lldb-dev]

On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Sep 21, 2016, at 1:55 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > :-/  The same thing happens if you write Foo &f = *nullptr;   It's a
> reference.
>
> I might be a good idea to add an overloaded constructor for nullptr and
> void * and delete them so that we can't implicitly create a StringRef from
> nullptr or NULL and cause as crash as it wouldn't compile in the first
> place.
>
> >
> > Did you try StringRef::withNullAsEmpty()?
>
> I am still catching code conversion issues with things like:
>
> if (name == nullptr)
>

Yea you have to handle it on a case by case basis.  What I've been doing is
to look around the surrounding code.  If it's obvious that it's not null
(because it was just checked above, or because it's .c_str() of something,
or it came from a string literal, or whatever, then i just call
llvm::StringRef(name);  If I don't know, even if I can probably guess, I do
one of two things.  If it seems like a rabbit hole you don't want to
venture into, just do withNullAsEmpty.  If it's a trivial utility function
that doesn't pass the string through many layers of nested calls, go change
that function to return a StringRef, then come back.

Another thing that's helped me a lot (although it will make the code
slightly verbose in the short term) is that any function I'm changing the
signature of from const char* to StringRef, copy the declaration and
=delete the const char* version.  This way the compiler won't allow the
implicit conversion, and you'll be forced to fix up every callsite.  This
is annoying because 99% of the time you end up explicitly constructing
StringRefs from literals, which will obviously work, but it's the only way
to guarantee that the conversion won't introduce null pointer errors.

Once the code is more or less done, we can go back and remove all the
=delete functions we added so you don't have to write explicit conversions
anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160921/dfdb672d/attachment.html>