xTachyon wrote:
@AaronBallman :smile:
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
https://github.com/xTachyon updated
https://github.com/llvm/llvm-project/pull/134551
>From 88a7517918ff8f6a5521527e9e1a141af09035c5 Mon Sep 17 00:00:00 2001
From: Andrei Damian
Date: Sun, 6 Apr 2025 19:55:59 +0300
Subject: [PATCH] clang_EvalResult_getAsCXString impl
---
clang/include/clang-c/
xTachyon wrote:
`CXString::private_flags` only has 2 bits used. Could we use the rest for the
size? Would it be enough?
There's also the possibility to not touch `CXString` at all, and add a function
that returns ptr+size only for `clang_EvalResult_getAs...`.
What do you think?
https://githu
@@ -52,6 +54,7 @@ typedef struct {
* to `std::string::c_str()`.
*/
CINDEX_LINKAGE const char *clang_getCString(CXString string);
+CINDEX_LINKAGE const char *clang_getCString2(CXString string, size_t *length);
xTachyon wrote:
I tried to find a macro that wrap
https://github.com/xTachyon created
https://github.com/llvm/llvm-project/pull/134551
Tries to implement #69749.
>From Discord:
`
In terms of how to solve it... I'm hoping we can extend CXString to be
length-aware and then add an interface that returns a CXString object instead.
Perhaps clang_
https://github.com/xTachyon updated
https://github.com/llvm/llvm-project/pull/134551
>From 88a7517918ff8f6a5521527e9e1a141af09035c5 Mon Sep 17 00:00:00 2001
From: Andrei Damian
Date: Sun, 6 Apr 2025 19:55:59 +0300
Subject: [PATCH 1/3] clang_EvalResult_getAsCXString impl
---
clang/include/clan
https://github.com/xTachyon updated
https://github.com/llvm/llvm-project/pull/134551
>From 88a7517918ff8f6a5521527e9e1a141af09035c5 Mon Sep 17 00:00:00 2001
From: Andrei Damian
Date: Sun, 6 Apr 2025 19:55:59 +0300
Subject: [PATCH 1/2] clang_EvalResult_getAsCXString impl
---
clang/include/clan
xTachyon wrote:
> What if we add unsigned clang_getCStringLength(CXString); which gets the
> length but not the contents? Do we need to package pointer and size together?
Where do we store the length, if we can't add a new field to `CXString`, and we
can't use `private_flags` to store it?
htt
xTachyon wrote:
> It means all such string accesses would require two indirections to get to
> the string data
I don't think that's true. Getting the pointer would be `ptr+sizeof(size_t)`.
> I also wonder if we want to be slightly less memory efficient and add a
> version field in case we nee
xTachyon wrote:
That's pretty much what I was thinking of in terms of implementation.
> and we'd need the versioning information if we had Clang N tracking length +
> contents and Clang N + 1 was tracking length + contents + encoding because
> the newer Clang would be casting to a pointer of t
https://github.com/xTachyon updated
https://github.com/llvm/llvm-project/pull/134551
>From 88a7517918ff8f6a5521527e9e1a141af09035c5 Mon Sep 17 00:00:00 2001
From: Andrei Damian
Date: Sun, 6 Apr 2025 19:55:59 +0300
Subject: [PATCH 1/3] clang_EvalResult_getAsCXString impl
---
clang/include/clan
xTachyon wrote:
We could keep `CXString` as it was before, but `const void *data` could
actually point to a dynamically allocated struct that has roughly this
definition:
```c
struct Data {
size_t length;
char data[1];
};
```
This wouldn't change the current API, and it would still be
12 matches
Mail list logo
