@@ -25,14 +25,19 @@ enum CXStringFlag {
/// CXString contains a 'const char *' that it doesn't own.
CXS_Unmanaged,
- /// CXString contains a 'const char *' that it allocated with malloc().
- CXS_Malloc,
+ /// CXString contains a 'CStringImpl' that it allocated with mall
@@ -25,14 +25,19 @@ enum CXStringFlag {
/// CXString contains a 'const char *' that it doesn't own.
CXS_Unmanaged,
- /// CXString contains a 'const char *' that it allocated with malloc().
- CXS_Malloc,
+ /// CXString contains a 'CStringImpl' that it allocated with mall
@@ -25,14 +25,19 @@ enum CXStringFlag {
/// CXString contains a 'const char *' that it doesn't own.
CXS_Unmanaged,
- /// CXString contains a 'const char *' that it allocated with malloc().
- CXS_Malloc,
+ /// CXString contains a 'CStringImpl' that it allocated with mall
https://github.com/andamian-bd deleted
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
@@ -25,14 +25,19 @@ enum CXStringFlag {
/// CXString contains a 'const char *' that it doesn't own.
CXS_Unmanaged,
- /// CXString contains a 'const char *' that it allocated with malloc().
- CXS_Malloc,
+ /// CXString contains a 'CStringImpl' that it allocated with mall
@@ -25,14 +25,19 @@ enum CXStringFlag {
/// CXString contains a 'const char *' that it doesn't own.
CXS_Unmanaged,
- /// CXString contains a 'const char *' that it allocated with malloc().
- CXS_Malloc,
+ /// CXString contains a 'CStringImpl' that it allocated with mall
@@ -44,6 +45,11 @@ typedef struct {
unsigned Count;
} CXStringSet;
+typedef struct {
+ const char *string;
+ size_t length;
+} CStringInfo;
AaronBallman wrote:
Because we can now feel a bit more free to add a different `private_flags`
value, I think we'r
https://github.com/xTachyon edited
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
@@ -44,6 +45,11 @@ typedef struct {
unsigned Count;
} CXStringSet;
+typedef struct {
+ const char *string;
+ size_t length;
+} CStringInfo;
xTachyon wrote:
Should we love space for possible expansion?
https://github.com/llvm/llvm-project/pull/134551
https://github.com/xTachyon updated
https://github.com/llvm/llvm-project/pull/134551
>From 6d8d8955c1e3c706e3195e440f9435e5ae197f9f 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/
AaronBallman wrote:
> I think this problem is an important one to solve, and this is not the first
> time our rigid ABI has caused us problems. I wonder at what point we should
> decide to break ABI, because there are other cleanups we also want to do
> (removing deprecated APIs, for example).
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
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
AaronBallman 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 fi
cor3ntin wrote:
@AaronBallman I missed most of the discussion here, but the underlying object
is an array. Trying to find the null terminator once the pointer has decayed
is asking for trouble. Is there a way to evaluate as an array? If not, that
might be a better direction. That would be les
AaronBallman 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 curre
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
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
AaronBallman 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
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
AaronBallman wrote:
> `CXString::private_flags` only has 2 bits used. Could we use the rest for the
> size? Would it be enough?
I'd be a bit uncomfortable with that. It would work, but it means we're never
able to add any new private flags in the future.
> There's also the possibility to not
@@ -5918,12 +5918,19 @@ clang_EvalResult_getAsUnsigned(CXEvalResult E);
CINDEX_LINKAGE double clang_EvalResult_getAsDouble(CXEvalResult E);
/**
- * Returns the evaluation result as a constant string if the
- * kind is other than Int or float. User must not free this pointer,
-
@@ -52,6 +54,12 @@ typedef struct {
* to `std::string::c_str()`.
*/
CINDEX_LINKAGE const char *clang_getCString(CXString string);
+/**
+ * This function behaves the same as clang_getCString, except that it also
+ * returns the size through the length parameter. The length par
@@ -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
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
AaronBallman wrote:
> What are the ABI guarantees of libclang? Won't adding a new field to CXString
> break compatibility?
That's a great point, it would be an ABI breaking change and we don't want
those in libclang:
https://github.com/llvm/llvm-project/blob/25e08c0b9cafaab09af35ce6a03317ffd5
@@ -52,6 +54,12 @@ typedef struct {
* to `std::string::c_str()`.
*/
CINDEX_LINKAGE const char *clang_getCString(CXString string);
+/**
+ * This function behaves the same as clang_getCString, except that it also
+ * returns the size through the length parameter. The length par
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
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 fl
@@ -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);
AaronBallman wrote:
We should document that `leng
@@ -14,6 +14,7 @@
#ifndef LLVM_CLANG_C_CXSTRING_H
#define LLVM_CLANG_C_CXSTRING_H
+#include
AaronBallman wrote:
Better to put this at the end of the include list; that leaves less chance for
those headers to accidentally transitively include stddef.h withou
https://github.com/AaronBallman edited
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:
@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
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Damian Andrei (xTachyon)
Changes
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 cl
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
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_
38 matches
Mail list logo
