[PATCH] D27475: [libFuzzer] Diff 17 - Implement DirName() for Windows.

[Marcos Pividori via llvm-commits]

@zturner @amccarth Thanks, you are right.
I think we could use Adrian's solution since the random access operator []
returns both const and non-const references. So, we can get a non-const
pointer.
I will update the diff.

On Tue, Dec 6, 2016 at 2:15 PM, Zachary Turner <zturner at google.com> wrote:

> &result[0] is const, you're going to have to const cast it to do that
> unfortunately.  Regardless though, manual new / delete is almost never the
> right solution.  For example, the original code could be replaced with
>
> ```
> std::vector<char> Buffer(FileName.begin(), FileName.end());
> Buffer.push_back(0);
> memcpy(&Buffer[0], FileName.data(), FileName.size());
> PathRemoveFileSpecA(&Buffer[0]);
> return std::string(&Buffer[0]);
> ```
>
> and it would be better than manually new'ing and deleting.  Unless you can
> accept the const_cast (which I'm not convinced we should in this case), the
> only alternative is stack allocating the buffer.
>
> BTW, if we could use llvm then this would be a perfect use case for
> StringRef :)  Oh well
>
> On Tue, Dec 6, 2016 at 2:03 PM Adrian McCarthy via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> amccarth added inline comments.
>>
>>
>> ================
>> Comment at: lib/Fuzzer/FuzzerIOWindows.cpp:144
>>  std::string DirName(const std::string &FileName) {
>> -  assert(0 && "Unimplemented");
>> +  char *Tmp = new char[FileName.size() + 1];
>> +  memcpy(Tmp, FileName.c_str(), FileName.size() + 1);
>> ----------------
>> Instead of managing memory yourself, I would just use another string as
>> the non-const buffer.  PathRemoveFileSpace may replace one of the
>> characters with '\0', so all you have to do is resize the result.
>>
>>     std::string result = FileName;
>>     PathRemoveFileSpecA(&result[0]);
>>     result.resize(std::strlen(result.c_str());
>>     return result;
>>
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D27475
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161206/a27ce42f/attachment.html>