在 2019/3/10 2:35, Ruslan Garipov 写道:
>> please do not include the diff of generated files
>
> Before I had changed 'mingw-w64-crt/Makefile.in' I thought
> 'mingw-w64-crt/configure' + automake regenerate the .in file from
> the updated .am ones. But I was wrong (well, I ain't an automake
>
On 3/9/19 6:35 PM, Ruslan Garipov wrote:
>> please do not include the diff of generated files
>
> Before I had changed 'mingw-w64-crt/Makefile.in' I thought
> 'mingw-w64-crt/configure' + automake regenerate the .in file from
> the updated .am ones. But I was wrong (well, I ain't an automake
>
> please do not include the diff of generated files
Before I had changed 'mingw-w64-crt/Makefile.in' I thought
'mingw-w64-crt/configure' + automake regenerate the .in file from
the updated .am ones. But I was wrong (well, I ain't an automake
expert, because I didn't use it in my everyday
在 2019/3/7 13:08, Ruslan Garipov 写道:
> Signed-off-by: Ruslan Garipov
> ---
> mingw-w64-crt/Makefile.in | 4 +-
Next time, please do not include the diff of generated files.
'Makefile.in' is generated from 'Makefile.am' using `autoreconf -if' so
only the diff of 'Makefile.am' need
> See the following code:
> (... trimmed ...)
Hao, thanks for explanations. Now I understand everything.
But please allow me to make some notes.
> struct foo
> {
> struct bar
> {
> char one;
> };
> char two;
> };
> ...
> // This prints 2 when compiled as C,
在 2019/3/3 0:35, Ruslan Garipov 写道:
>>> 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.
>>
>> This is an important difference between C and C++.
>
> I'm
>> 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.
>
> This is an important difference between C and C++.
I'm sorry, but I'm confused a little bit: what is
> 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
在 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
did you mean the members of `struct _LBA {` in the aforementioned commit
would be members of the enclosing `struct _PLAY_CD {`? This seems the case
in C.
Yes, members of `_LBA` and `_MSF` becomes members of `_PLAY_CD` when
compiling such C code with GCC on Microsoft Windows. At least it
在 2019/3/1 上午12:22, Ruslan Garipov 写道:
> That commit does what you've suggested to me to fix build with g++: it
> moves two structure definition out of an anonymous union. That's what
> I've done already and that's what has "broken" my C compilers on
> Microsoft Windows. But the commit
> I am not familiar with CC. Perhaps it is just a symlink to GCC
Yes, cc is a soft link to gcc. I just got into the habit of using CC,
not GCC. Therefore, the problem I wanted to show you in my previous
message is that GCC for Microsoft Windows can't compile the sample with
two structures
在 2019/2/28 下午8:23, Ruslan Garipov 写道:
> Hello, Hao! Thanks a lot for review!
>
>> This could be fixed by defining the struct inside `SSVARIANT`
>> directly
>
> Yes, if I implement the `SSVARIANT` like this:
>
> (... abridged ...)
>
> g++ compiles the file just fine. But now we get errors
Hello, Hao! Thanks a lot for review!
This could be fixed by defining the struct inside `SSVARIANT`
directly
Yes, if I implement the `SSVARIANT` like this:
```
struct SSVARIANT {
SSVARTYPE vt;
DWORD dwReserved1;
DWORD dwReserved2;
struct _Time2Val {
DBTIME2 tTime2Val;
BYTE bScale;
在 2019/2/28 4:25, Ruslan Garipov 写道:
>> it does apply cleanly to the master branch.
>> Please rebase this work against master
>
> I believe the issue here is not the master's tip. That's line-ending
> issue.
>
Yes killing all CRs makes the patch apply again.
But this is unusual. Git should be
> it does apply cleanly to the master branch.
> Please rebase this work against master
I believe the issue here is not the master's tip. That's line-ending
issue.
Before I sent the original patch here, I had created it on top of
'ce5078c9' commit. This was and currently is the head.
After I
在 2019/2/27 19:20, Ruslan Garipov 写道:
> In August of 2011[1] Microsoft announced deprecation of the Microsoft
> OLE DB Provider for SQL Server. But in October of 2017 Microsoft had to
> undeprecate[2] OLE DB data access technology releasing the ``Microsoft
> OLE DB Driver for SQL Server'' known
17 matches
Mail list logo
