ImportC: Should this compile?

Mike Parker aldacron at
Sun Dec 19 02:57:35 UTC 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:

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 

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:

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:

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.

More information about the Digitalmars-d-learn mailing list