[LLDB] Cast to pointer-to-array-of-typeof-variable doesn't work

[jacobef]

p *(typeof(*s)(*)[3])s, where s is a pointer to (say) 3 elements, does not work.

System: M1 Macbook Air, macOS Sequoia 15.6 (24G84), see below for clang and lldb versions.
Reproduction:

$ clang --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ lldb --version
lldb-1700.0.9.502
Apple Swift version 6.1.2 (swiftlang-6.1.2.1.2 clang-1700.0.13.5)
$ cat > repro.c <<EOF
> int main(void) {
> char *s = "abc";
> }
> EOF
$ clang -g repro.c -o repro
$ lldb ./repro
(lldb) target create "./repro"
Current executable set to '/Users/friedman/Coding/Misc/repro' (arm64).
(lldb) break set -n main
Breakpoint 1: where = repro`main + 4 at repro.c:2:7, address = 0x000000010000037c
(lldb) run
Process 3984 launched: '/Users/friedman/Coding/Misc/repro' (arm64)
Process 3984 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000010000037c repro`main at repro.c:2:7
   1   	int main(void) {
-> 2   	char *s = "abc";
   3   	}
Target 0: (repro) stopped.
(lldb) step
Process 3984 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
    frame #0: 0x0000000100000388 repro`main at repro.c:3:1
   1   	int main(void) {
   2   	char *s = "abc";
-> 3   	}
Target 0: (repro) stopped.
(lldb) p *(typeof(*s)(*)[3])s
                       ˄
                       ╰─ error: expected expression

This also reproduces with LLDB 20.1.8, installed via Homebrew.
Notably, p *(char(*)[3])s works fine; this is only a problem with typeof.
*(typeof(*s)(*)[3])s is in fact a valid expression, i.e. LLDB is incorrect to reject it, because the following compiles fine in clang:

int main(void) {
    char *s = "abc";
    *(typeof(*s)(*)[3])s;
}

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Jacob Friedman (jacobef)

`p *(typeof(*s)(*)[3])s`, where `s` is a pointer to (say) 3 elements, does not work.

System: M1 Macbook Air, macOS Sequoia 15.6 (24G84), see below for clang and lldb versions.
Reproduction:

$ clang --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ lldb --version
lldb-1700.0.9.502
Apple Swift version 6.1.2 (swiftlang-6.1.2.1.2 clang-1700.0.13.5)
$ cat > repro.c <<EOF
> int main(void) {
> char *s = "abc";
> }
> EOF
$ clang -g repro.c -o repro
$ lldb ./repro
(lldb) target create "./repro"
Current executable set to '/Users/friedman/Coding/Misc/repro' (arm64).
(lldb) break set -n main
Breakpoint 1: where = repro`main + 4 at repro.c:2:7, address = 0x000000010000037c
(lldb) run
Process 3984 launched: '/Users/friedman/Coding/Misc/repro' (arm64)
Process 3984 stopped
* thread #<!-- -->1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x000000010000037c repro`main at repro.c:2:7
   1   	int main(void) {
-&gt; 2   	char *s = "abc";
   3   	}
Target 0: (repro) stopped.
(lldb) step
Process 3984 stopped
* thread #<!-- -->1, queue = 'com.apple.main-thread', stop reason = step in
    frame #<!-- -->0: 0x0000000100000388 repro`main at repro.c:3:1
   1   	int main(void) {
   2   	char *s = "abc";
-&gt; 3   	}
Target 0: (repro) stopped.
(lldb) p *(typeof(*s)(*)[3])s
                       ˄
                       ╰─ error: expected expression

This also reproduces with LLDB 20.1.8, installed via Homebrew.
Notably, p *(char(*)[3])s works fine; this is only a problem with typeof.
*(typeof(*s)(*)[3])s is in fact a valid expression, i.e. LLDB is incorrect to reject it, because the following compiles fine in clang:

int main(void) {
    char *s = "abc";
    *(typeof(*s)(*)[3])s;
}

[Michael137]

The unsatisfying answer is that LLDB expressions are always compiled as C++ (because we need some of the C++ features to make the machinery work). If you compile your test program as c++ you'd get the same error:

main.cpp:3:17: error: expected expression
    3 |   *(typeof(*s)(*)[3])s;

[jacobef]

@Michael137 Is there a valid way to do that cast in C++, then? I just need some general way to cast a pointer to pointer-to-array, for the purpose of a "show pointer as array" option in a debugger frontend I'm working on.

[Edit: Never mind, figured out a workaround specific to that frontend]

[Michael137]

@Michael137 Is there a valid way to do that cast in C++, then? I just need some general way to cast a pointer to pointer-to-array, for the purpose of a "show pointer as array" option in a debugger frontend I'm working on.

TBH, I'm not sure why typeof specifically doesn't work, since the following does work In C++:

(std::remove_reference_t<decltype(*s)>(*)[3])s;

Might be worth filing another issue against the Clang component for this.

The decltype trick wouldn't work in the expression evaluator either though because we currently don't support instantiating templates. You could probably make the cast work using the SBAPI.

But also I suspect this wouldn't actually solve your problem. LLDB would print the casted type as:

(lldb) v
(char *) s = 0x00000001000003d8 "abc"
(std::remove_reference_t<decltype(*s)> (*)[3]) ptr = 0x00000001000003d8

(lldb) p *ptr
(std::remove_reference_t<decltype(*s)>[3]) "abc"

Looks like this is specific to char* though? For ints, casting to pointer-to-array works fine.

There is the parray command which does the heavy lifting for you (even for char*):

(lldb) parray 3 s
(char *) $0 = 0x0000000100000578 "abc" {
  [0] = 'a'
  [1] = 'b'
  [2] = 'c'
}

Would that suffice for your use-case? However, general recommendation is to avoid running expressions in things like formatters. Could you elaborate on the needs of your front-end? Maybe there's a better way to go about this

[jacobef]

Might be worth filing another issue against the Clang component for this.

GCC also rejects it in C++ mode (and accepts it in C mode), so I assume it's not a Clang bug.

Would that suffice for your use-case? However, general recommendation is to avoid running expressions in things like formatters. Could you elaborate on the needs of your front-end? Maybe there's a better way to go about this

I've now figured out a workaround specific to that frontend, but thanks for the help. (If you're curious, I wanted to add a button under the options menu for pointer variables, which would add it as a watch as an array, like CLion's "view as array" option. The frontend, which is part of Zed, already uses CodeLLDB, which supports the var,[n] syntax for this purpose, so I can just use that.)

[Michael137]

GCC also rejects it in C++ mode (and accepts it in C mode), so I assume it's not a Clang bug.

Thanks for confirming. (could still be a bug in both :) this is a non-standard extension so I think there's more room for unexpected/odd behaviour from both compilers).

I've now figured out a workaround specific to that frontend, but thanks for the help. (If you're curious, I wanted to add a button under the options menu for pointer variables, which would add it as a watch as an array, like CLion's "view as array" option. The frontend, which is part of Zed, already uses CodeLLDB, which supports the var,[n] syntax for this purpose, so I can just use that.)

👍

Going to close then. Feel free to reopen if there's still an issue here

[jacobef]

Sounds good. On the slim chance that someone else faces this same problem, *(typeof(typeof(*s))(*)[3])s seems to work (for whatever reason).

[Michael137]

Sounds good. On the slim chance that someone else faces this same problem, *(typeof(typeof(*s))(*)[3])s seems to work (for whatever reason).

Hehe weird. Filed #152274

[labath]

The decltype trick wouldn't work in the expression evaluator either though because we currently don't support instantiating templates.

It wouldn't, but you can remove the reference by forcing a lvalue-to-rvalue conversion (or whatever is the proper name for that): decltype(+*x)(*)[3]

Not to say that using this for any serious business is a good idea...