Obtaining an address given a (run time) variable name

[Jonathan M Davis]

On Sunday, January 26, 2025 4:41:53 PM MST DLearner via Digitalmars-d-learn wrote:
> On Monday, 20 January 2025 at 19:54:19 UTC, Jonathan M Davis
> wrote:
> [...]
> > Also, there's really no reason to be doing anything with char[]
> > instead of string unless you're specifically planning on
> > mutating the elements in your string, and casting from a string
> > literal to a char[] is almost never a good idea, because it
> > means that you could end up mutating the elements, which would
> > violate the type system guarantees - since immutable values are
> > never supposed to be mutated, and the compiler will potentially
> > make the assumption that an immutable value was not mutated
> > (string is an alias for immutable(char)[], and string literals
> > are strings). If you _do_ need to mutate the string for some
> > reason, then use dup to get a mutable copy rather than casting
> > the literal, e.g.
> >
> >     char[] wkVarName = "IntVar3".dup;
> >
> > - Jonathan M Davis
>
> Probably I misunderstand, but using -betterC:
>
> ```
> extern (C) void main() {
>
>     char[] Name;
>
>     Name = "InitName".dup;
> //   Name = cast(char[])("InitName");
>
> }
> ```
> fails to compile, but
> ```
> extern (C) void main() {
>
>     char[] Name;
>
> //   Name = "InitName".dup;
>     Name = cast(char[])("InitName");
>
> }
> ```
> compiles.

If you're using -betterC, then you're stripping out a bunch of language
features (including the runtime and the GC). dup uses the GC, as do many
operations on dynamic arrays. You can slice other types of memory to get a
dyamic array, you can read the elements, and you can shrink the dynamic
array, but you can't increase it in size or cause it to reallocate in any
way without the GC - including calling dup.

String literals are compiled into the binary, so they're slices of that
memory and do not require the GC, whereas calling dup on a string literal
then does require the GC, because it's allocating a new string.

Casting a string literal to char[] is throwing away immutable, and casting
away const or immutable is not something that you normally want to do,
because the type system requires that immutable values never be mutated and
that const values never be mutated via a non-mutable reference, and you
cannot mutate them by getting a mutable reference via casting. The mutable
reference needs to have been mutable from the get-go. So, while you are
allowed to cast away const or immutable (and sometimes, that can be quite
useful), it is a violation of the type system to then mutate that data, if
you do mutate that dat, you risk subtle bugs due to the compiler assuming
that the data wasn't actually mutated. And in the case of a string literal,
depending on the OS, you actually risk crashing your program if the literal
was put in read-only memory and then you mutate it after casting away const
or immutable.

As such, you really shouldn't be casting string literals to char[]. The way
that the language provides to get a char[] from a string literal is to call
dup to allocate a new array that's mutable and copy the elements. However,
if you're using -betterC, you're choosing to not use some core parts of the
language, and you're losing out on some capabilities - like the ability to
allocate a new array with dup, and so with -betterC, if you want a char[]
from a string literal, you'll have to do something like allocate it with
malloc and copy the elements yourself. Pretty much the only reason that you
should ever consider casting away const or immutable from a string is you're
passing it to a function that takes a char[] or char*, and you know for sure
that it's not actually going to mutate the data.

And just FYI, -betterC is really only intended for porting C code to D code
piece by piece by making it so that you don't need to involve the D runtime
in the beginning of the process. You can choose to use it for entire
projects, but that's not what it's intended for, and you lose out on
language features if you do. And in a lot of cases, you're going to be on
your own to figure out how to do stuff.

- Jonathan M Davis