[PATCH] D25255: Add a c_str() method to StringRef, similar to data() but asserting if the string isn't null terminated (NFC)

[Chandler Carruth via llvm-commits]

On Tue, Oct 4, 2016 at 6:52 PM Duncan P. N. Exon Smith via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
> > On 2016-Oct-04, at 18:20, Mehdi Amini via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >
> >>
> >> On Oct 4, 2016, at 6:16 PM, Mehdi Amini via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >>
> >>>
> >>> On Oct 4, 2016, at 6:11 PM, Zachary Turner <zturner at google.com> wrote:
> >>>
> >>> One possible way to make this actually be *safe* is to privately
> inherit ZeroStringRef from StringRef and bring in all the base class
> functions via using declarations.  EXCEPT those base class functions that
> CANNOT un null terminate a null terminated string (eg drop_front() etc).
> For those functions, reimplement them to return a ZeroStringRef.
> >>>
> >>> Allow StringRef to be implicitly constructed from ZSR but not the
> other way around
> >>
> >> Yeah, that may be the best way forward. Also removing the StringRef
> constructor from a "const char *” at the same time.
> >>
> >> I’ll try this after I’m done with my queue of StringRef conversions.
> >
> > I’m not sure how it’ll look like on the API side though.
>
> Just to address these specifically (I'm not entirely convinced of adding
> an inheritance relationship, or even of adding CStringRef at all (not
> against it, just not convinced)).
>

FWIW, I'm actually mildly against. At least as it is being discussed below.

I think we should not be spreading the usage of nul-terminated strings. The
situations where they are needed are, IMO, very rare and we would be better
off taking a different approach. Trying to keep all our strings null
terminated or trying to adapt every API that *can* produce a null
terminated string ref to do so seems like it will be a lot of work for what
becomes relatively little gain.

As specific examples: if we need a compressed way to represent a string in
a single pointer, cool. I can imagine doing this with a wrapper around a
character pointer. But I would have that wrapper support very few if any
direct APIs and instead I would have it almost immediately call 'strlen'
and build a real StringRef to expose outside of the implementation where
the compressed storage is needed.

In other cases I could imagine wanting a pointer into a table of StringRefs
that refer to, for example, a prefix-trie of string data.

There are lots of ways to get a compressed storage type, I wouldn't try to
expose one of them across lots of APIs as it'll just leak the compression
implementation technique across the abstraction boundary. The
implementation of the compression (or storage) becomes part of the
interface in a way that I think would be bad.


Anyways, maybe all of this is moot for now...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161005/dc498f39/attachment.html>