> This can be verified by printing the size of the enclosing struct
> using GCC with our header, then comparing it with the result using
> MSVC and Microsoft header.
Nifty :-) Actually I've believed that **declaration** of nested
structures is just a declaration, and no code/data will be generated for
that. But it turns out that I was wrong.
Thus, if I have the following sample.c file:
```
struct A
{
struct B {int b;};
struct C {int c;};
};
int
main(void)
{
return sizeof (struct A);
}
```
and compile it with GCC v8.2.1 on a Linux-based OS I get:
```
$ x86_64-pc-linux-gnu-gcc gcc -O2 -S -o - sample.c
...
xorl %eax, %eax
ret
```
Well, that's fine -- I get an empty `struct A`, just as it was declared.
But if I compile the file with x86_64-w64-mingw32-gcc on Microsoft
Windows:
```
$ x86_64-w64-mingw32-gcc -O2 -S -o - sample.c
...
movl $8, %eax
...
ret
```
Oops... I get a non-empty (!) `struct A` with two 4-bytes `int` fields!
That's a bug I believe. :-(
> It would result in duplicated definitions which I think is pretty bad
Okay, I will publish new patch for reviewing on the next Tuesday,
3/5/2019, after 3:00 AM UTC. Unfortunately, I can't publish it earlier.
Thanks!
On 3/1/2019 7:33 PM, Liu Hao wrote:
> 在 2019/3/1 15:14, Ruslan Garipov 写道:
>>> It looks like we have ended up in a bug there
>>
>> I don't know :-( To summarize: MSVC, Intel C++ and GCC on Microsoft
>> Windows fail to compile that sample C code. But clang for Microsoft
>> Windows does compile the code (just like GCC for Linux-based OSes).
>> clang-cl fails to compile of course; due to the back-end shared with
>> MSVC I believe.
>>
>
> This can be verified by printing the size of the enclosing struct using
> GCC with our header, then comparing it with the result using MSVC and
> Microsoft header.
>
>>> I think we should try promoting named nested structs and unions (so
>>> they appear in the file scope). At least this works for both C and
>>> C++, providing these names don't conflict with each other.
>>
>> If I understand you correctly, you propose to move declarations of the
>> nested structures like `_Time2Val`, `_DateTimeVal` and so on out of
>> declaration of the `SSVARIANT` structure (where they will be at the file
>> scope)? For both C and C++.
>>
>> I've also proposed the same thing but for C only, because such moving
>> out does not change senantics. Had I compiled the code with nested
>> structures successfully by a C compiler, the nested structures are at
>> unit scope I believe:
>>
>
> Yes. This results in consistent code, and doesn't bring duplication of
> the struct definition (outside the struct for C and inside it for C++).
>
>>> 6.7.2.1 Structure and union specifiers
>>> 8 The presence of a struct-declaration-list in a
>>> struct-or-union-specifier declares a new type, within a translation unit.
>>
>> But for C++ to preserve† isolation of the nested types (as it is in the
>> original header file) we may stick with a fix I've already shown -- a
>> fix proposed by you, Hao (declaring structure types before an anonymous
>> union having members of those types).
>>
>> Therefore, I want to use `#ifdef __cplusplus` to separate these two
>> solutions.
>>
>> † 10.3.10 Nested class declarations [class.nest]
>> 1 ... The name of a nested class is local to its enclosing class. The
>> nested class is in the scope of its enclosing class.
>>
>>
>
> It would result in duplicated definitions which I think is pretty bad.
>
>
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
