Given:

===============
extern(C):
char*[] hldr;
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }

void main(){}
===============

How do I initialize an instance of S at global scope?

// Not sure how to do this... so try to keep as close to original as possible
// Nope, does not work
S[] s = [
    {
        cast(char*)"c",
        &hldr[0],
        I
    },
]

// Error: static variable C_HL_extensions cannot be read at compile time
S[] s = [ S(cast(char*)"c", &hldr[0], I) ];

// Error Deprecation: static constructor can only be of D linkage
S[] s;
static this() {
    s = [ S(cast(char*)"c", &hldr[0], I) ];
}

Thanks,
Andrew

On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
> Given:
>
> ===============
> extern(C):
> char*[] hldr;
> enum I = (1<<0);
> struct S { char* ft; char** fm; int f; }
>
> void main(){}
> ===============
>
> How do I initialize an instance of S at global scope?

You cant. At the global scope the initializers must be runnable at compile time, i.e using CTFE. I've tried to simplify what would be required:

---
extern(C):
char*[] hldr;
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }

void main(){}

enum char[8] FirstLevel  = ['0'];
enum         DoubleLevel = &FirstLevel[0]; // here

S[] s = [
    S(
        FirstLevel.ptr,
        DoubleLevel,          // error is here actually, interesting
        0),
];
---

D is not able of that :

/tmp/temp_7F835402B0F0.d:9:28: Error: cannot use non-constant CTFE pointer in an initializer `&['0', '\xff', '\xff', '\xff', '\xff', '\xff', '\xff', '\xff'][0]`

On Monday, 7 December 2020 at 05:28:41 UTC, user1234 wrote:
> On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
>> Given:
>>
>> ===============
>> extern(C):
>> char*[] hldr;
>> enum I = (1<<0);
>> struct S { char* ft; char** fm; int f; }
>>
>> void main(){}
>> ===============
>>
>> How do I initialize an instance of S at global scope?
>
> You cant. At the global scope the initializers must be runnable at compile time, i.e using CTFE. I've tried to simplify what would be required:
>
> ---
> extern(C):
> char*[] hldr;
> enum I = (1<<0);
> struct S { char* ft; char** fm; int f; }
>
> void main(){}
>
> enum char[8] FirstLevel  = ['0'];
> enum         DoubleLevel = &FirstLevel[0]; // here
>
> S[] s = [
>     S(
>         FirstLevel.ptr,
>         DoubleLevel,          // error is here actually, interesting
>         0),
> ];
> ---
>
> D is not able of that :
>
> /tmp/temp_7F835402B0F0.d:9:28: Error: cannot use non-constant CTFE pointer in an initializer `&['0', '\xff', '\xff', '\xff', '\xff', '\xff', '\xff', '\xff'][0]`

sorry my example was bad, better one

---
extern(C):
char*[] hldr;
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }

void main(){}

enum char[8] Stuff      = ['0'];
enum         FirstLevel = Stuff.ptr; // &Suffn so char* OK

S[] s = [
    S(
        FirstLevel,                           // char* OK
        &FirstLevel, // error here               char** NG at CTFE
        0),
];
---

On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
> Given:
>
> ===============
> extern(C):
> char*[] hldr;
> enum I = (1<<0);
> struct S { char* ft; char** fm; int f; }
>
> void main(){}
> ===============
>
> // Error Deprecation: static constructor can only be of D linkage
> S[] s;
> static this() {
>     s = [ S(cast(char*)"c", &hldr[0], I) ];
> }

This is the correct way to do it. The problem is that you have added `extern(C):` at the top. This means that ever symbol below will have C linkage. As the error message says, `static this` can only have D linkage. `static this` is transformed into a function which is automatically called by the runtime. When you add `extern(C):` at the top, this function will also get the C linkage. A simple way to make sure that there are not multiple C functions with the same name (caused by multiple `static this`, in the same file or another file) is to mangle the function name the same way as a D function.

You can either use `extern(C) char*[] hldr` to make only `hldr` have C linkage. Use `extern(C) {}` to group several symbols which should have C linkage or rearrange the code so that `static this` is above `extern(C):`.

--
/Jacob Carlborg

On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
> Given:
>
> ===============
> extern(C):
> char*[] hldr;

Why is this extern(C)? A D array ere is probably wrong.

In C, a `char*[] hldr = {...}` is actually represented in D as a static length array, like `char*[1] = [null];`

It should also generally be __gshared if it was declared in C (C defaults to global, D defaults to thread-local), and if declared in C, an additional extern may be required.


So, if you are trying to *link* to C code that has this:

---
// C
char* hldr[] = {0};
---

You'd bind to it in D with

---
// D
extern(C) extern __gshared char*[1] hldr; // matches the C. Make sure the length matches too

// rest for your code the same:
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }

S[] s = [S(cast(char*) "c", &hldr[0])]; // that cast is super iffy though. Should S have `const(char)* ft` instead?

void main(){}
---


In that thing:

extern(C) - tells it it has a C name.
extern - tells it the actual variable is declared externally. This second one makes the linker pull the variable's address from the C code instead of declaring a new variable in D that can be used from C.
__gshared - turn off D's thread local default to match C's global.



Now if you are translating C code to D, that might be different, certainly the second extern is wrong then, and you need to copy over the initial value but the rest still works:

```
// no more second extern, D is now creating a new variable, then it needs to know the value too
extern(C) __gshared char*[1] hldr = [null];

// rest is the same
// including
S[] s = [S(cast(char*) "c", &hldr[0])]; // since it is a gshared static array, this still works
```



But there's a few other contexts that might change this, then you probably do want the static constructor, or maybe you can make some things immutable and make it work that way. All depends on a bit more information than your code gives on its own....

On 12/7/20 10:12 PM, Jacob Carlborg wrote:
> On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
> 
> You can either use `extern(C) char*[] hldr` to make only `hldr` have C linkage. Use `extern(C) {}` to group several symbols which should have C linkage or rearrange the code so that `static this` is above `extern(C):`.
> 
> -- 
> /Jacob Carlborg

Thanks Jacob. The extern(C) is temporary. I'm doing a direct port of the code to D using -betterC. Wanted to keep it as close to the original as possible until everything compiles.

I noticed that static this() does not work if either it or main() (or both) is marked extern(C). To fix the issue, I simply moved the static this() and main() above the extern(C) and the deprecation error disappears.

Andrew

On 12/7/20 10:56 PM, Adam D. Ruppe wrote:
> On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
>> Given:
>>
>> ===============
>> extern(C):
>> char*[] hldr;
> 
> Why is this extern(C)? A D array ere is probably wrong.

To stay as close to the original implementation as possible. This will all change when the entire code base compiles in D.

> In C, a `char*[] hldr = {...}` is actually represented in D as a static length array, like `char*[1] = [null];`

Thanks. Because I was having issues I didn't know how to resolve, I actually defined it as `string ft` instead and passed around `ft.ptr` when calling

> It should also generally be __gshared if it was declared in C (C defaults to global, D defaults to thread-local), and if declared in C, an additional extern may be required.
> 

Noted. I'll keep that in mind when trying to link to C in the future.

> 
> So, if you are trying to *link* to C code that has this:
> 

I'm porting it. All of the code is available from the D source file.

> 
> You'd bind to it in D with
> 
> ---
> // D
> extern(C) extern __gshared char*[1] hldr; // matches the C. Make sure the length matches too

Ok, got it.

> S[] s = [S(cast(char*) "c", &hldr[0])]; // that cast is super iffy though. Should S have `const(char)* ft` instead?
> 

Probably. I just did a direct port. They had char* so I just kept it that way. I'll change it to string once the initial port is complete. But I'll remember that when I come across it in the future.

> 
> In that thing:
> 
> extern(C) - tells it it has a C name.
> extern - tells it the actual variable is declared externally. This second one makes the linker pull the variable's address from the C code instead of declaring a new variable in D that can be used from C.
> __gshared - turn off D's thread local default to match C's global.
> 

Learning has occurred. Thanks.

> 
> Now if you are translating C code to D, that might be different, certainly the second extern is wrong then, and you need to copy over the initial value but the rest still works:

This.

> ```
> // no more second extern, D is now creating a new variable, then it needs to know the value too
> extern(C) __gshared char*[1] hldr = [null];

Okay. I'll need to be mindful of this in the future. But to resolve the issue this time around, I just used a string[] since that's the end state anyway.

> // rest is the same
> // including
> S[] s = [S(cast(char*) "c", &hldr[0])]; // since it is a gshared static array, this still works
> ```

Yup... got this to compile with main() and static this() in the correct location.

> 
> But there's a few other contexts that might change this, then you probably do want the static constructor, or maybe you can make some things immutable and make it work that way. All depends on a bit more information than your code gives on its own....

Thanks for the lesson... I've learned quite a lot.

On Tuesday, 8 December 2020 at 01:47:51 UTC, Andrew Edwards wrote:

> Thanks Jacob. The extern(C) is temporary. I'm doing a direct port of the code to D using -betterC. Wanted to keep it as close to the original as possible until everything compiles.

Yes, that's always a good idea. Do the initial port as close as possible to the original code. Then refactor and start adding D specific features.

> I noticed that static this() does not work if either it or main() (or both) is marked extern(C).

Yes, that's expected. If you have a regular D main function, the compiler will recognize that and output an undefined symbol to the C main function. The C main function is implemented in the D runtime. The C runtime will call the C main function in the D runtime. The C main function is responsible for initializing the D runtime. This includes (not a complete list):

* Converting the arguments passed to the C main function to `string[]`
* Initializing the garbage collector
* Calling `shared static this()` in all modules
* Calling `static this()` in all modules
* Running the any unit tests
* Finally calling the D main function

When you define a C main function the compiler will recognize that and not output an undefined symbol. That means the C main function in the D runtime will never be called. That means the D runtime is never initialized. This is to allow you to use D without its runtime or get more control of the startup phase.

So either either you define a D main function and everything works as expected or you define a C main function and then you need to manually initialize and deinitialize the D runtime, if you want to use it. This can be done with [1] and [2].

[1] https://dlang.org/phobos/core_runtime.html#.rt_init
[2] https://dlang.org/phobos/core_runtime.html#.rt_term

--
/Jacob Carlborg