This is an archive of the discontinued LLVM Phabricator instance.

Add a c_str() method to StringRef, similar to data() but asserting if the string isn't null terminated (NFC)
AbandonedPublic

Authored by mehdi_amini on Oct 4 2016, 2:57 PM.

Details

Summary

As I'm trying to replace our uses of raw "const char *"
with StringRef, one issue that came up is that calling .data()
on a StringRef is seen as "dangerous": there is no guarantee
that the String will be null terminated.

This is an attempt to alleviate this issue: instead of calling
data(), users that knows (because of an API contract) that a
StringRef must be null terminated can call c_str() instead.

Event Timeline

mehdi_amini updated this revision to Diff 73558.Oct 4 2016, 2:57 PM
mehdi_amini retitled this revision from to Add a c_str() method to StringRef, similar to data() but asserting if the string isn't null terminated (NFC).
mehdi_amini updated this object.
mehdi_amini added reviewers: dexonsmith, kimgr.
mehdi_amini added a subscriber: llvm-commits.
zturner edited edge metadata.Oct 4 2016, 3:22 PM

Not sure how I feel about this. It's convenient, but it has potential for abuse. Where did you run into issues porting code to StringRef that this solves? I've done a lot of StringRef porting in LLDB by now, and I've always managed to find a solution to this. Usually it involves trickling the StringRef changes down further (often in a separate CL that can be made more isolated) and then coming back to your original CL, where now you have StringRefs to work with rather than const char *. Does that not work in your cases?

Not sure how I feel about this. It's convenient, but it has potential for abuse. Where did you run into issues porting code to StringRef that this solves?

I ran into this with "printf" like API at some point, or with places that can't be converted to StringRef because of space constraint, like MachineOperand. So you're out of the IR and you have to use .data() to initialize the MO. Later you may construct a StringRef from this "const char *" again.

I've done a lot of StringRef porting in LLDB by now, and I've always managed to find a solution to this. Usually it involves trickling the StringRef changes down further

Usually that's what I do, yes. The problem is when you reach some cases like above.

mehdi_amini abandoned this revision.Oct 4 2016, 6:16 PM

The conclusion on the email thread is that StringRef is not suitable to represent C-string, and we need a new separate class for that. In the meantime, clients will have to live with .data()