<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 4, 2016 at 6:52 PM Duncan P. N. Exon Smith via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 2016-Oct-04, at 18:20, Mehdi Amini via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
>><br class="gmail_msg">
>> On Oct 4, 2016, at 6:16 PM, Mehdi Amini via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> On Oct 4, 2016, at 6:11 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> 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.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Allow StringRef to be implicitly constructed from ZSR but not the other way around<br class="gmail_msg">
>><br class="gmail_msg">
>> Yeah, that may be the best way forward. Also removing the StringRef constructor from a "const char *” at the same time.<br class="gmail_msg">
>><br class="gmail_msg">
>> I’ll try this after I’m done with my queue of StringRef conversions.<br class="gmail_msg">
><br class="gmail_msg">
> I’m not sure how it’ll look like on the API side though.<br class="gmail_msg">
<br class="gmail_msg">
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)).<br class="gmail_msg"></blockquote><div><br></div><div>FWIW, I'm actually mildly against. At least as it is being discussed below.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Anyways, maybe all of this is moot for now...</div></div></div>