digitalmars.D.learn - ImportC: Should this compile?
- bachmeier (20/20) Dec 18 2021 I've been trying to get the stb header library to compile.
- Mike Parker (32/52) Dec 18 2021 Unless C11 has changed the rules about nested initializers, that
- Tejas (19/76) Dec 18 2021 Yes, using the nested initializer worked
- Mike Parker (5/8) Dec 18 2021 If the name of the file with `main` were used, you'd have to have
- bachmeier (4/61) Dec 19 2021 Thanks - issues created:
I've been trying to get the stb header library to compile.
There's a single remaining failure:
```
typedef struct
{
unsigned char c[4];
} stb_easy_font_color;
stb_easy_font_color c = { 255,255,255,255 }; // use structure
copying to avoid needing depending on memcpy()
```
LDC returns
```
stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct
__tag21`
```
Is this a bug in ImportC or is it correct that it doesn't
compile? What's the best way to fix it while keeping the same
behavior and performance? (I don't know what struct __tag21 is.
It's not anywhere in the source. Assuming that's just a bad error
message.)
Dec 18 2021
On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote:I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { 255,255,255,255 }; // use structure copying to avoid needing depending on memcpy() ``` LDC returns ``` stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct __tag21` ``` Is this a bug in ImportC or is it correct that it doesn't compile? What's the best way to fix it while keeping the same behavior and performance?Unless C11 has changed the rules about nested initializers, that should compile. You might try explicit nesting: ```d stb_easy_font_color c = { {255,255,255,255} }; ``` And please file an issue if there isn't one already.(I don't know what struct __tag21 is. It's not anywhere in the source. Assuming that's just a bad error message.)A "tag" is the name of a struct or union, which follows the keyword: ```c struct Foo {}; ``` Here, `Foo` is the tag. Instances of the struct must be declared as `struct Foo`. Think of it like this: `int` is required in declarations of instances of type `int`, so `struct` is required in declarations of type `struct`; the "tag" specifies which struct type, hence `struct Foo x`. `typedef` introduces an alias: ```c typedef struct Bar {} Bar; ``` So `Bar` is now an alias for `struct Bar`, and instances can be declared as `Bar x`. Your example is like this: ```c typedef struct {} stb_easy_font_color; ``` No tag is specified, so the compiler must generate one. In your case, it's `__tag21` and `stb_easy_font_color` is an alias for `struct __tag21`. And yes, using the generated tag in the error message is not at all helpful without the alias. Please file an issue on this, too.
Dec 18 2021
On Sunday, 19 December 2021 at 02:57:35 UTC, Mike Parker wrote:On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote:Yes, using the nested initializer worked ```c typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { { 255,255,255,255 } }; // use structure copying to avoid needing depending on memcpy() ``` d file: ```d void main(){} ``` command line: ` dmd stuff.c main.d` Oh wow, the executable gets named `stuff` if that's the first file passed... always thought it would name it the same name as that file which contained `main`I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { 255,255,255,255 }; // use structure copying to avoid needing depending on memcpy() ``` LDC returns ``` stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct __tag21` ``` Is this a bug in ImportC or is it correct that it doesn't compile? What's the best way to fix it while keeping the same behavior and performance?Unless C11 has changed the rules about nested initializers, that should compile. You might try explicit nesting: ```d stb_easy_font_color c = { {255,255,255,255} }; ``` And please file an issue if there isn't one already.(I don't know what struct __tag21 is. It's not anywhere in the source. Assuming that's just a bad error message.)A "tag" is the name of a struct or union, which follows the keyword: ```c struct Foo {}; ``` Here, `Foo` is the tag. Instances of the struct must be declared as `struct Foo`. Think of it like this: `int` is required in declarations of instances of type `int`, so `struct` is required in declarations of type `struct`; the "tag" specifies which struct type, hence `struct Foo x`. `typedef` introduces an alias: ```c typedef struct Bar {} Bar; ``` So `Bar` is now an alias for `struct Bar`, and instances can be declared as `Bar x`. Your example is like this: ```c typedef struct {} stb_easy_font_color; ``` No tag is specified, so the compiler must generate one. In your case, it's `__tag21` and `stb_easy_font_color` is an alias for `struct __tag21`. And yes, using the generated tag in the error message is not at all helpful without the alias. Please file an issue on this, too.
Dec 18 2021
Mike Parker <aldacron gmail.com> On Sunday, 19 December 2021 at 03:27:50 UTC, Tejas wrote:Oh wow, the executable gets named `stuff` if that's the first file passed... always thought it would name it the same name as that file which contained `main`If the name of the file with `main` were used, you'd have to have a different default for libraries. Executables and libraries get the name of the first source file passed on the command line by default. This can be overridden with -of.
Dec 18 2021
On Sunday, 19 December 2021 at 02:57:35 UTC, Mike Parker wrote:On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote:Thanks - issues created: [Issue 1](https://issues.dlang.org/show_bug.cgi?id=22610) [Issue 2](https://issues.dlang.org/show_bug.cgi?id=22611)I've been trying to get the stb header library to compile. There's a single remaining failure: ``` typedef struct { unsigned char c[4]; } stb_easy_font_color; stb_easy_font_color c = { 255,255,255,255 }; // use structure copying to avoid needing depending on memcpy() ``` LDC returns ``` stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct __tag21` ``` Is this a bug in ImportC or is it correct that it doesn't compile? What's the best way to fix it while keeping the same behavior and performance?Unless C11 has changed the rules about nested initializers, that should compile. You might try explicit nesting: ```d stb_easy_font_color c = { {255,255,255,255} }; ``` And please file an issue if there isn't one already.(I don't know what struct __tag21 is. It's not anywhere in the source. Assuming that's just a bad error message.)A "tag" is the name of a struct or union, which follows the keyword: ```c struct Foo {}; ``` Here, `Foo` is the tag. Instances of the struct must be declared as `struct Foo`. Think of it like this: `int` is required in declarations of instances of type `int`, so `struct` is required in declarations of type `struct`; the "tag" specifies which struct type, hence `struct Foo x`. `typedef` introduces an alias: ```c typedef struct Bar {} Bar; ``` So `Bar` is now an alias for `struct Bar`, and instances can be declared as `Bar x`. Your example is like this: ```c typedef struct {} stb_easy_font_color; ``` No tag is specified, so the compiler must generate one. In your case, it's `__tag21` and `stb_easy_font_color` is an alias for `struct __tag21`. And yes, using the generated tag in the error message is not at all helpful without the alias. Please file an issue on this, too.
Dec 19 2021