https://github.com/AaronBallman commented:
> 1 Is size_t appropriate here? I see some functions using unsigned, and some > using size_t. I think it's an appropriate type to use (`unsigned` would also be fine, but I tend to prefer `size_t` for this sort of use, personally). > 2 On this new flow to get a string literal, there's at least 2 allocations of > the string from the 2 cxstring::createDup, one when evaluating the result, > and one when returning it. Is this ok/can it be done better? I was thinking about that and I think it's okay. We do not have a public `createDup()` interface for `CXString`, which means returning a `CXString` with the same lifetime as the eval result can be a bit tricky because the user has to do their own buffer management if they want the string to outlive the eval results. If we had such a public interface, then I would think it's better to not have the second duplicate and leave it to the caller to decide the lifetime questions. > 3 Is returning a "null" CXString on error a good idea? I think so. I've added a few more reviewers for some broader opinions. https://github.com/llvm/llvm-project/pull/134551 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
