Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 > expert, because I didn't use it in my everyday workflow, sorry), and I > failed to build new mingw-w64's CRT having libmsoledbsql.a. Therefore, > I updated 'mingw-w64-crt/Makefile.in', which is under git control. > The shorthand to update those scripts is `autoreconf -if`. Sometimes this is necessary because files checkout from a version control system might not have correct timestamps, or due to lack of `make` dependencies because of wildcard rules. Personally I don't have these files in my repositories so they have to be generated always after a working tree is checked out. This has the advantage that generated files are never committed into the repo. On the other hand, this requires other users to have autotools installed so they can't build the project with only a shell, make, and a compiler. >> 'Makefile.in' is generated from 'Makefile.am' using `autoreconf -if' > > Do I understand correctly that 'mingw-w64-crt/Makefile.in' must be > checked in via dedicated commits like 4ed230ca? > Exactly. > > Oh, sorry for that -- it's my habit to put semicolon even after macro. > I've known it results in double semicolons after preprocessor, and some > compilers may warn about that... I'm sorry, and thanks for fix that. > This macro is not supposed to behave like an expression, so the semicolon which would follow it wouldn't make sense. >> Thank you very much for the work and the discussion. The patch looks >> good now. I amended the patch and pushed it. > > I thank you too for your review, fixes and conversation! It was nice > experience for me! > My pleasure. I'm looking forward to your next contribution! -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
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 > expert, because I didn't use it in my everyday workflow, sorry), and I > failed to build new mingw-w64's CRT having libmsoledbsql.a. Therefore, > I updated 'mingw-w64-crt/Makefile.in', which is under git control. > >> 'Makefile.in' is generated from 'Makefile.am' using `autoreconf -if' > > Do I understand correctly that 'mingw-w64-crt/Makefile.in' must be > checked in via dedicated commits like 4ed230ca? > > ``` > $ git log --oneline mingw-w64-crt/Makefile.in | grep [Rr]egenerate > 4ed230ca crt: Regenerate configure. > 8fcb463f crt: Regenerate Makefile.in. > d72c4fe6 crt: Regenerate configure. > 9077bf73 crt: Regenerate Makefile.in > 161a6439 crt: Regenerate Makefile.in > b84ab0fc crt: Regenerate Makefile.in > ... Yes, they are checked in as separate commits, usually done by the ones doing the push. That means you don't need to specifically send a review for the regenerated files. signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
> 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 workflow, sorry), and I
failed to build new mingw-w64's CRT having libmsoledbsql.a. Therefore,
I updated 'mingw-w64-crt/Makefile.in', which is under git control.
> 'Makefile.in' is generated from 'Makefile.am' using `autoreconf -if'
Do I understand correctly that 'mingw-w64-crt/Makefile.in' must be
checked in via dedicated commits like 4ed230ca?
```
$ git log --oneline mingw-w64-crt/Makefile.in | grep [Rr]egenerate
4ed230ca crt: Regenerate configure.
8fcb463f crt: Regenerate Makefile.in.
d72c4fe6 crt: Regenerate configure.
9077bf73 crt: Regenerate Makefile.in
161a6439 crt: Regenerate Makefile.in
b84ab0fc crt: Regenerate Makefile.in
...
```
> There shall be no semicolons following
> `MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS`
Oh, sorry for that -- it's my habit to put semicolon even after macro.
I've known it results in double semicolons after preprocessor, and some
compilers may warn about that... I'm sorry, and thanks for fix that.
> Thank you very much for the work and the discussion. The patch looks
> good now. I amended the patch and pushed it.
I thank you too for your review, fixes and conversation! It was nice
experience for me!
On 3/9/2019 7:42 AM, Liu Hao wrote:
> 在 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 appear in the patch. I removed this
> from the patch.
>
> For this patch there is no modification to 'Makefile.am', however.
>
>> mingw-w64-crt/lib32/Makefile.am | 1 +
>> mingw-w64-crt/lib32/msoledbsql.def | 13 +
>> mingw-w64-crt/lib64/Makefile.am | 1 +
>> mingw-w64-crt/lib64/msoledbsql.def | 13 +
>> mingw-w64-headers/include/msoledbsql.h | 1452
>> 6 files changed, 1482 insertions(+), 2 deletions(-)
>> create mode 100644 mingw-w64-crt/lib32/msoledbsql.def
>> create mode 100644 mingw-w64-crt/lib64/msoledbsql.def
>> create mode 100644 mingw-w64-headers/include/msoledbsql.h
>>
>
>> +#ifndef __cplusplus
>> + MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS;
>> +#endif
>> +struct SSVARIANT {
>> + SSVARTYPE vt;
>> + DWORD dwReserved1;
>> + DWORD dwReserved2;
>> + /* For C++ code (`-x c++`/`-Tp`) we may move the declarations here.
>> This, at
>> + * least, limits scope of the declarations to the `SSVARIANT` structure,
>> if we
>> + * compare declaration of the structures at the global scope (as it's
>> made for
>> + * C code). Both variants break public API of the original header file,
>> but
>> + * unfortunately that's unavoidable. */
>> +#ifdef __cplusplus
>> + MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS;
>> +#endif
>
> There shall be no semicolons following
> `MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS`. I removed them, too.
>
> Thank you very much for the work and the discussion. The patch looks
> good now. I amended the patch and pushed it.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 appear in the patch. I removed this
from the patch.
For this patch there is no modification to 'Makefile.am', however.
> mingw-w64-crt/lib32/Makefile.am | 1 +
> mingw-w64-crt/lib32/msoledbsql.def | 13 +
> mingw-w64-crt/lib64/Makefile.am | 1 +
> mingw-w64-crt/lib64/msoledbsql.def | 13 +
> mingw-w64-headers/include/msoledbsql.h | 1452
> 6 files changed, 1482 insertions(+), 2 deletions(-)
> create mode 100644 mingw-w64-crt/lib32/msoledbsql.def
> create mode 100644 mingw-w64-crt/lib64/msoledbsql.def
> create mode 100644 mingw-w64-headers/include/msoledbsql.h
>
> +#ifndef __cplusplus
> + MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS;
> +#endif
> +struct SSVARIANT {
> + SSVARTYPE vt;
> + DWORD dwReserved1;
> + DWORD dwReserved2;
> + /* For C++ code (`-x c++`/`-Tp`) we may move the declarations here. This,
> at
> + * least, limits scope of the declarations to the `SSVARIANT` structure,
> if we
> + * compare declaration of the structures at the global scope (as it's made
> for
> + * C code). Both variants break public API of the original header file,
> but
> + * unfortunately that's unavoidable. */
> +#ifdef __cplusplus
> + MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS;
> +#endif
There shall be no semicolons following
`MSOLEDBSQL_H_DECL_SSVARIANT_STRUCTS`. I removed them, too.
Thank you very much for the work and the discussion. The patch looks
good now. I amended the patch and pushed it.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
> 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, because the member `one` of
> // `struct bar` is a member of the enclosing struct i.e. `foo`.
> // This prints 1 when compiled as C++.
> printf("%d\n", (int)sizeof(struct foo));
With C compilers that prints ``2'' **sometimes** :-) Because of
`-fms-extensions`[1].
When it's on (and for mingw it's on by default), compiling your sample
with the following command:
```
$ x86_64-w64-mingw32-gcc -x c -std=c17 -O2 -S -fms-extensions \
-o - sample.c
```
results in:
```
movl$2, %edx ; `sizeof(struct foo)`
callprintf
```
And with `-fms-extensions` turned off:
```
$ x86_64-w64-mingw32-gcc -x c -std=c17 -O2 -S -fno-ms-extensions \
-o - sample17.c
...
movl$1, %edx
callprintf
```
This is why I've got inconsistent results with different C
compilers[2][3]. Therefore, the following code (the second version of
the patch):
```
struct SSVARIANT {
/* declaration of some fields */
struct _Time2Val {
DBTIME2 tTime2Val;
BYTE bScale;
};
...
};
```
isn't always valid for a C compiler because of:
a) some C compilers know about `-fms-extensions`, and if the latter is
used, the `_Time2Val` becomes[1] anonymous structure, and, as a
consequence, the members of the `_Time2Val` are considered to be members
of the `SSVARIANT`[4]. This, I believe, changes layout of structure in
memory, when compare it with "original" structure (from my initial
patch). Moreover, when several structures like the `_Time2Val` and
`_DateTimeVal` have members of the same name (the `bScale` in this
case), we end up with a compilation error[3].
b) for all other C compilers there's no much sense to declare structures
like the `_Time2Val` within the `SSVARIANT`. Semantically it declares
all those structures at scope where the header is included (6.2.1 Scopes
of identifiers). The original version of the patch provides some
"logical locality" of declarations of the tags like `_Time2Val`,
combining a structure declaration with field definition, but it doesn't
change semantics: the tags are available after the completion of their
corresponding declarators at scope where the header is included.
Therefore, as we've already discussed, for a C compiler we may declare
the `_Time2Val` structure and others just before the `SSVARIANT`
structure. But for a C++ compiler we should avoid that, I believe,
because original API of msoledbsql.h file doesn't have such a type like
`::_Time2Val`. We should preserve the
`SSVARIANT::{unnamed union}::_Time2Val` type, but there's another broken
"feature" of Microsoft Visual C++.
Errors which Liu Hao found[5] when compiling the code with g++, are the
result of:
> 10.4.1 Anonymous unions [class.union.anon]
> 1 ... Each member-declaration in the member-specification of an
> anonymous union shall either define a non-static data member or be a
> static_assert-declaration. [Note: Nested types, anonymous unions, and
> functions cannot be declared within an anonymous union. -end note]
But MSVC ignores that and compiles the following code successfully:
```
struct SSVARIANT
{
union
{
struct _Time2Val
{
} Time2Val;
};
};
```
GNU C++ is not compatible with such behavior. Moreover, GNU C++ doesn't
allow `typedef`s within anonymous unions (again because of
[class.union.anon]). Therefore, we can't declare a type like
`SSVARIANT::{unnamed union}::_Time2Val` with GNU C++. We may declare[5]
all such types directly inside `SSVARIANT` (for C++ **only** -- see
above), creating the types like `SSVARIANT::_Time2Val`, but we change
original API of msoledbsql.h again -- there are no such types there.
Thus, I believe, it's impossible to reproduce that (original) code,
which is specific to Microsoft "extensions", in a form compatible with
the C++ standard.
We may move all those types (`_Time2Val` and others) out from the
`SSVARIANT` completely (just as we already did that for C, we may do
that for C++), and end up with `::_Time2Val`, `::_DateTimeVal`, etc. for
a C++ compiler. Yes, it also modifies the original API, but unify the
code which declares the `SSVARIANT` between C and C++. Though I believe
that having the types scoped to the `SSVARIANT` (`SSVARIANT::_Time2Val`,
`SSVARIANT::_DateTimeVal`, etc.) is the lesser of two evils. And for
the latter I have only not-very-beautiful solution with a preprocessor
macro.
> The typedef there is to make the qualified name `SSVARIANT::_Time2Val`
> valid in C++, as in the old, non-working code.
I see, thanks once again for explanation!
[1]: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
"6.63 Unnamed Structure and Union Fields"
[2]: https://sourceforge.net/p/mingw-w64/mailman/message/36600915/
[3]:
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 sorry, but I'm confused a little bit: what is ``this'' that "is an
> important difference between C and C++"? I've talked (the quote of me
> above) about C compilers only, and I was wondering how you could
> predicate that members of the nested structures (**from their
> declarations**) become **real** members of the enclosing structure. :-)
> Would you please explain me your thoughts?
>
See the following code:
```
#include
struct foo
{
struct bar
{
char one;
};
char two;
};
int main(void)
{
// This prints 2 when compiled as C, because the member `one` of
// `struct bar` is a member of the enclosing struct i.e. `foo`.
// This prints 1 when compiled as C++.
printf("%d\n", (int)sizeof(struct foo));
#ifndef __cplusplus
// In C the nested struct is defined in the file scope.
printf("%d\n", (int)sizeof(struct bar));
#else
// This is the C++ way of referring the nested struct.
printf("%d\n", (int)sizeof(foo::bar));
#endif
}
```
> But what has confused me more is your sample. A joke :-) The following
> discussion in this message assumes that we are talking about C++
> compilers only.
>
> ```
> #ifdef __cplusplus
> typedef struct _Time2Val _Time2Val
> #endif
> ```
>
> Okay, I understand that here you declares new ``typedef-name'' (the
> "second" `_Time2Val`) for naming ``elaborated-type-specifier''
> (`struct _Time2Val`). What I do **not** understand is why you've
> introduced that ``typedef-name''? What is its purpose? To use it in
> the next field declaration? But why not just use
> ``elaborated-type-specifier'' "directly" there?
>
> The next statement is:
>
> ```
> struct _Time2Val Time2Val;
> ```
>
> I'm sorry, but it's "ill-formed"
>
>> 9.1.7.3 Elaborated type specifiers [dcl.type.elab]
>> 2 ... If the identifier resolves to a typedef-name ..., the
>> elaborated-type-specifier is ill-formed.
>> ...
>> 3 ... Thus, in any elaborated-type-specifier, ... either the class or
>> struct class-key shall be used to refer to a class (Clause 10)
>> declared using the class or struct class-key.
>
> Here is your sample on Matt Godbolt's ``Compiler explorer'':
> https://godbolt.org/z/1RVfhQ (I simplified the sample, renamed
> identifiers (`_Time2Val` -> `A`; `SSVARIANT` -> `B`; `Time2Val` ->
> `a`) and removed the anonymous `union` -- it doesn't play a role there).
> GCC (and some others (clang, icc, but not msvc)) failed to compile the
> sample with this error (after "translating" names back): "using
> typedef-name 'SSVARIANT::{unnamed union}::_Time2Val' after 'struct'" --
> this what [dcl.type.elab] (2) is talking about.
>
> But it doesn't matter, though. What I really want to understand is what
> did you want to do, Hao. Please, explain, it's very important to me.
The typedef there is to make the qualified name `SSVARIANT::_Time2Val`
valid in C++, as in the old, non-working code.
In C++ `typedef _Time2Val _Time2Val` is *sometimes* incorrect.
>
> And what I've planned to post on the next Tuesday is something like
> this:
>
> ```
> define MSOLEDBSQL_H_DECL_VAR_TYPES do { \
> struct _Time2Val { \
> DBTIME2 tTime2Val; \
> BYTE bScale; \
> }; \
> struct _DateTimeVal { \
> ... and so on: declare all "nested" structs here ..
> }; \
> } while (0)
> #ifndef __cplusplus
> MSOLEDBSQL_H_DECL_VAR_TYPES;
> #endif
> struct SSVARIANT {
> /* declaration of some fields */
> #ifdef __cplusplus
> MSOLEDBSQL_H_DECL_VAR_TYPES;
> #endif
> union {
> /* declaration of some other fields */
> _Time2Val Time2Val;
> _DateTimeVal DateTimeVal;
> ...
> };
> };
> ```
>
> May be this is not a sophisticated solution, but it's a simple one (for
> me) and it avoids double declaration problem.
>
That is not very friendly and should be the very last option I think.
--
Best regards,
LH_Mouse
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
>> 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'' that "is an
important difference between C and C++"? I've talked (the quote of me
above) about C compilers only, and I was wondering how you could
predicate that members of the nested structures (**from their
declarations**) become **real** members of the enclosing structure. :-)
Would you please explain me your thoughts?
But what has confused me more is your sample. A joke :-) The following
discussion in this message assumes that we are talking about C++
compilers only.
```
#ifdef __cplusplus
typedef struct _Time2Val _Time2Val
#endif
```
Okay, I understand that here you declares new ``typedef-name'' (the
"second" `_Time2Val`) for naming ``elaborated-type-specifier''
(`struct _Time2Val`). What I do **not** understand is why you've
introduced that ``typedef-name''? What is its purpose? To use it in
the next field declaration? But why not just use
``elaborated-type-specifier'' "directly" there?
The next statement is:
```
struct _Time2Val Time2Val;
```
I'm sorry, but it's "ill-formed"
> 9.1.7.3 Elaborated type specifiers [dcl.type.elab]
> 2 ... If the identifier resolves to a typedef-name ..., the
> elaborated-type-specifier is ill-formed.
> ...
> 3 ... Thus, in any elaborated-type-specifier, ... either the class or
> struct class-key shall be used to refer to a class (Clause 10)
> declared using the class or struct class-key.
Here is your sample on Matt Godbolt's ``Compiler explorer'':
https://godbolt.org/z/1RVfhQ (I simplified the sample, renamed
identifiers (`_Time2Val` -> `A`; `SSVARIANT` -> `B`; `Time2Val` ->
`a`) and removed the anonymous `union` -- it doesn't play a role there).
GCC (and some others (clang, icc, but not msvc)) failed to compile the
sample with this error (after "translating" names back): "using
typedef-name 'SSVARIANT::{unnamed union}::_Time2Val' after 'struct'" --
this what [dcl.type.elab] (2) is talking about.
But it doesn't matter, though. What I really want to understand is what
did you want to do, Hao. Please, explain, it's very important to me.
And what I've planned to post on the next Tuesday is something like
this:
```
define MSOLEDBSQL_H_DECL_VAR_TYPES do { \
struct _Time2Val { \
DBTIME2 tTime2Val; \
BYTE bScale; \
}; \
struct _DateTimeVal { \
... and so on: declare all "nested" structs here ..
}; \
} while (0)
#ifndef __cplusplus
MSOLEDBSQL_H_DECL_VAR_TYPES;
#endif
struct SSVARIANT {
/* declaration of some fields */
#ifdef __cplusplus
MSOLEDBSQL_H_DECL_VAR_TYPES;
#endif
union {
/* declaration of some other fields */
_Time2Val Time2Val;
_DateTimeVal DateTimeVal;
...
};
};
```
May be this is not a sophisticated solution, but it's a simple one (for
me) and it avoids double declaration problem.
On 3/2/2019 7:38 AM, Liu Hao wrote:
> 在 2019/3/2 上午2:13, Ruslan Garipov 写道:
>>> 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.
>>
>
> This is an important difference between C and C++.
>
> Well I think we may try this:
>
> ```
> struct _Time2Val
> {
> // some fields...
> };
>
> struct SSVARIANT
> {
> // some fields...
> union // anonymous union
> {
> #ifdef __cplusplus
> // The elaborated-type-specifier will reference the struct
> // in the global namespace and its use is mandatory here.
> typedef struct _Time2Val _Time2Val
> #endif
> struct _Time2Val Time2Val;
> };
> };
> ```
>
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
> 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
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
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 looks
like that, when one reads the error text.
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.
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:
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.
On March 1, 2019 7:42:24 AM Liu Hao wrote:
在 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 'a66e407e' is "lucky" to have those
two structures (`_LBA` and `_MSF`) having no members of the same name.
And in my case I have, for example, `_Time2Val`, `_DateTimeVal` and
`_DateTimeOffsetVal` all having the `bScale` members, which the
compilers erroneously "inserts" as members into `SSVARIANT` and,
therefore, fail with error.
... 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. It looks like we have ended up in a bug there.
Thus, what about using `#ifdef __cplusplus` guard?
But 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.
--
Best regards,
LH_Mouse
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 'a66e407e' is "lucky" to have those
> two structures (`_LBA` and `_MSF`) having no members of the same name.
> And in my case I have, for example, `_Time2Val`, `_DateTimeVal` and
> `_DateTimeOffsetVal` all having the `bScale` members, which the
> compilers erroneously "inserts" as members into `SSVARIANT` and,
> therefore, fail with error.
>
... 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. It looks like we have ended up in a bug there.
> Thus, what about using `#ifdef __cplusplus` guard?
>
But 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.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
> 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 nested into another one. Just as Microsoft Visual C++
and Intel C++ (same back-end?) -- all three compilers fail to compile
the sample with ``duplicate member''/``*member* has already been
declared in the current scope'' error. GCC for a Linux-distro target
compiles the sample without any error.
> See a66e407efbadeeca6a0bdb4fd7b39a6f8275958f . It looks like a similar
> issue
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 'a66e407e' is "lucky" to have those
two structures (`_LBA` and `_MSF`) having no members of the same name.
And in my case I have, for example, `_Time2Val`, `_DateTimeVal` and
`_DateTimeOffsetVal` all having the `bScale` members, which the
compilers erroneously "inserts" as members into `SSVARIANT` and,
therefore, fail with error.
Thus, what about using `#ifdef __cplusplus` guard?
On 2/28/2019 6:24 PM, Liu Hao wrote:
> 在 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 with cc
>> compiler:
>>
>> (... abridged ...)
>>
>> It looks like the compiler sees the both `Foo` and `Boo` type
>> declarations as declarations of *anonymous structures*, whose members
>> must be considered as members of the containing structure ([6.7.2.1] 13
>> Structure and union specifiers).
>>
>> x86_64-pc-linux-gnu-cc compiles the same code just well, without error.
>>
>> Therefore, I want to propose to use `#ifdef __cplusplus` on the updated
>> `SSVARIANT` structure shown in this post to declare "new" dedicated
>> nested structures (`_{Time2,DateTime{,Offset},NChar,...}Val`) as
>> **nested** ones only for C++, and to declare the same structures for C
>> just before the declaration of the `SSVARIANT` structure† (or to use
>> "original" version of the `SSVARIANT` structure).
>>
>> † If one moves declaration of the `Foo` and `Boo` out of the declaration
>> of the `A` structure, x86_64-w64-mingw32-cc compiles the sample.c
>> without any errors.
>>
>> What do you think about this?
>>
>
>
> See a66e407efbadeeca6a0bdb4fd7b39a6f8275958f . It looks like a similar
> issue, so I presume a similar solution would apply. If it fails with CC
> then probably CC is out of interest.
>
> Hmm I am not familiar with CC. Perhaps it is just a symlink to GCC and
> GCC behaves like sort of ancient compiler if it finds itself being
> called 'CC'... ?
>
--
Yours truly,
Ruslan Garipov .
--
MinGW-w64 developer, with write after approval
GEDKeeper collaborator
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 with cc
> compiler:
>
> (... abridged ...)
>
> It looks like the compiler sees the both `Foo` and `Boo` type
> declarations as declarations of *anonymous structures*, whose members
> must be considered as members of the containing structure ([6.7.2.1] 13
> Structure and union specifiers).
>
> x86_64-pc-linux-gnu-cc compiles the same code just well, without error.
>
> Therefore, I want to propose to use `#ifdef __cplusplus` on the updated
> `SSVARIANT` structure shown in this post to declare "new" dedicated
> nested structures (`_{Time2,DateTime{,Offset},NChar,...}Val`) as
> **nested** ones only for C++, and to declare the same structures for C
> just before the declaration of the `SSVARIANT` structure† (or to use
> "original" version of the `SSVARIANT` structure).
>
> † If one moves declaration of the `Foo` and `Boo` out of the declaration
> of the `A` structure, x86_64-w64-mingw32-cc compiles the sample.c
> without any errors.
>
> What do you think about this?
>
See a66e407efbadeeca6a0bdb4fd7b39a6f8275958f . It looks like a similar
issue, so I presume a similar solution would apply. If it fails with CC
then probably CC is out of interest.
Hmm I am not familiar with CC. Perhaps it is just a symlink to GCC and
GCC behaves like sort of ancient compiler if it finds itself being
called 'CC'... ?
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
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;
};
struct _DateTimeVal {
DBTIMESTAMP tsDateTimeVal;
BYTE bScale;
};
struct _DateTimeOffsetVal {
DBTIMESTAMPOFFSET tsoDateTimeOffsetVal;
BYTE bScale;
};
struct _NCharVal {
SHORT sActualLength;
SHORT sMaxLength;
WCHAR *pwchNCharVal;
BYTE rgbReserved[5];
DWORD dwReserved;
WCHAR *pwchReserved;
};
struct _CharVal {
SHORT sActualLength;
SHORT sMaxLength;
CHAR *pchCharVal;
BYTE rgbReserved[5];
DWORD dwReserved;
WCHAR *pwchReserved;
};
struct _BinaryVal {
SHORT sActualLength;
SHORT sMaxLength;
BYTE *prgbBinaryVal;
DWORD dwReserved;
};
struct _UnknownType {
DWORD dwActualLength;
BYTE rgMetadata[16];
BYTE *pUnknownData;
};
struct _BLOBType {
DBOBJECT dbobj;
IUnknown *pUnk;
};
union {
BYTE bTinyIntVal;
SHORT sShortIntVal;
LONG lIntVal;
LONGLONG llBigIntVal;
FLOAT fltRealVal;
DOUBLE dblFloatVal;
CY cyMoneyVal;
VARIANT_BOOL fBitVal;
BYTE rgbGuidVal[16];
DB_NUMERIC numNumericVal;
DBDATE dDateVal;
DBTIMESTAMP tsDateTimeVal;
struct _Time2Val Time2Val;
struct _DateTimeVal DateTimeVal;
struct _DateTimeOffsetVal DateTimeOffsetVal;
struct _NCharVal NCharVal;
struct _CharVal CharVal;
struct _BinaryVal BinaryVal;
struct _UnknownType UnknownType;
struct _BLOBType BLOBType;
};
};
```
g++ compiles the file just fine. But now we get errors with cc
compiler:
```
$ cc -std=gnu11 -Wall -Wextra -x c \
mingw-w64-headers/include/msoledbsql.h -o /dev/null
mingw-w64-headers/include/msoledbsql.h:355:10: error: duplicate member
'bScale'
BYTE bScale;
^~
```
This is because x86_64-w64-mingw32-cc v8.2.1 (just as v8.1.0) fails to
compile the following code (sample.c):
```
struct A
{
struct Foo {int foo; int bar;};
struct Boo {int boo; int bar;};
};
int
main(void)
{
return 0;
}
```
emitting the same error as above:
```
$ cc -std=c17 -Wall -Wextra -x c sample.c -o /dev/null
sample.c:4:28: error: duplicate member 'bar'
struct Boo {int boo; int bar;};
^~~
```
It looks like the compiler sees the both `Foo` and `Boo` type
declarations as declarations of *anonymous structures*, whose members
must be considered as members of the containing structure ([6.7.2.1] 13
Structure and union specifiers).
x86_64-pc-linux-gnu-cc compiles the same code just well, without error.
Therefore, I want to propose to use `#ifdef __cplusplus` on the updated
`SSVARIANT` structure shown in this post to declare "new" dedicated
nested structures (`_{Time2,DateTime{,Offset},NChar,...}Val`) as
**nested** ones only for C++, and to declare the same structures for C
just before the declaration of the `SSVARIANT` structure† (or to use
"original" version of the `SSVARIANT` structure).
† If one moves declaration of the `Foo` and `Boo` out of the declaration
of the `A` structure, x86_64-w64-mingw32-cc compiles the sample.c
without any errors.
What do you think about this?
On February 28, 2019 8:01:02 AM Liu Hao wrote:
在 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 able to ignore CRs before LFs. :|
Thanks a lot! I'll add your fix to the next version of the patch. But
I also didn't tested it because I have no i686-w64-mingw32 toolset.
This is actually the reason why I didn't create the DEF file for x86
library by myself.
Thanks a lot for review. I will send the new patch by the next message.
Hope it could be applied well.
The proposed patch contains an error when compiled as C++:
+struct SSVARIANT {
+ SSVARTYPE vt;
+ DWORD dwReserved1;
+ DWORD dwReserved2;
+ union {
+BYTE bTinyIntVal;
+SHORT sShortIntVal;
+LONG lIntVal;
+LONGLONG llBigIntVal;
+FLOAT fltRealVal;
+DOUBLE dblFloatVal;
+CY cyMoneyVal;
+VARIANT_BOOL fBitVal;
+BYTE rgbGuidVal[16];
+DB_NUMERIC numNumericVal;
+DBDATE dDateVal;
+DBTIMESTAMP tsDateTimeVal;
+struct _Time2Val {
+ DBTIME2 tTime2Val;
+ BYTE bScale;
+} Time2Val;
The `_Time2Val` (with a few more) would be invalid C++, as follows:
```
$ g++ -std=gnu++11 -Wall -Wextra -x c++
mingw-w64-headers/include/msoledbsql.h -o /dev/null
mingw-w64-headers/include/msoledbsql.h:367:12: error: 'struct
SSVARIANT_DateTimeVal' invalid; an anonymous union
may only have public non-static data members [-fpermissive]
struct _DateTimeVal {
^~~~
```
This could be fixed by defining the struct inside `SSVARIANT` directly,
as follows:
```
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 able to ignore CRs before LFs. :|
>
> Thanks a lot! I'll add your fix to the next version of the patch. But
> I also didn't tested it because I have no i686-w64-mingw32 toolset.
> This is actually the reason why I didn't create the DEF file for x86
> library by myself.
>
> Thanks a lot for review. I will send the new patch by the next message.
> Hope it could be applied well.
>
The proposed patch contains an error when compiled as C++:
> +struct SSVARIANT {
> + SSVARTYPE vt;
> + DWORD dwReserved1;
> + DWORD dwReserved2;
> + union {
> +BYTE bTinyIntVal;
> +SHORT sShortIntVal;
> +LONG lIntVal;
> +LONGLONG llBigIntVal;
> +FLOAT fltRealVal;
> +DOUBLE dblFloatVal;
> +CY cyMoneyVal;
> +VARIANT_BOOL fBitVal;
> +BYTE rgbGuidVal[16];
> +DB_NUMERIC numNumericVal;
> +DBDATE dDateVal;
> +DBTIMESTAMP tsDateTimeVal;
> +struct _Time2Val {
> + DBTIME2 tTime2Val;
> + BYTE bScale;
> +} Time2Val;
The `_Time2Val` (with a few more) would be invalid C++, as follows:
```
$ g++ -std=gnu++11 -Wall -Wextra -x c++
mingw-w64-headers/include/msoledbsql.h -o /dev/null
mingw-w64-headers/include/msoledbsql.h:367:12: error: 'struct
SSVARIANT_DateTimeVal' invalid; an anonymous union
may only have public non-static data members [-fpermissive]
struct _DateTimeVal {
^~~~
```
This could be fixed by defining the struct inside `SSVARIANT` directly,
as follows:
```
struct SSVARIANT {
SSVARTYPE vt;
DWORD dwReserved1;
DWORD dwReserved2;
struct _Time2Val {
DBTIME2 tTime2Val;
BYTE bScale;
};
union {
BYTE bTinyIntVal;
SHORT sShortIntVal;
LONG lIntVal;
LONGLONG llBigIntVal;
FLOAT fltRealVal;
DOUBLE dblFloatVal;
CY cyMoneyVal;
VARIANT_BOOL fBitVal;
BYTE rgbGuidVal[16];
DB_NUMERIC numNumericVal;
DBDATE dDateVal;
DBTIMESTAMP tsDateTimeVal;
struct _Time2Val Time2Val;
```
So, please fix this issue and send a new patch.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
> 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 had got your reply, I downloaded the DIFF from my own e-mail and tried to apply the patch to the head by myself: $ git pull origin master $ patch -u -p 1 < 0001-Add-...diff $ git apply 0001-Add-...diff where the `patch` warned about CRs in the DIFF, but applied the patch; and `git-apply(1)` failed to patch the files with "trailing whitespaces" error. Therefore, I modified both two last commands to: $ tr -d '\r' < 0001-Add-...diff | patch -u -p1 $ tr -d '\r' < 0001-Add-...diff | git apply - And now any of the commands patches the files successfully. That all is really strange because I didn't change my workflow, so I sent the patch as usual: I created a patch using `git-format-patch(1)` and then `git-imap-send(1)` it. `git-format-patch(1)` creates a file with LF as line-ending. After I send the file using `git-imap-send(1)` (with msys2 or Arch Linux's git), I get a new e-mail in the ``Drafts'' with CRLF as line-endings in the patch part of the e-mail (CRLF in an e-mail is okay, as far as I know, but may be I'm wrong). I'm sorry, but now I really don't know how to send the patch with LF line-endings, so you can apply my patch... I rechecked my old patches and other people's patches in this mailing list -- it looks like they all have CRLF as line-endings. I'm totally confused now. > The x86 import library was absent Yes, that's my fault. > I have attached an (albeit untested) one, generated using 'gendef' > from the x86 DLL. Thanks a lot! I'll add your fix to the next version of the patch. But I also didn't tested it because I have no i686-w64-mingw32 toolset. This is actually the reason why I didn't create the DEF file for x86 library by myself. Thanks a lot for review. I will send the new patch by the next message. Hope it could be applied well. -- Yours truly, Ruslan Garipov . -- MinGW-w64 developer, with write after approval GEDKeeper collaborator ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server
在 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 as ``msoledbsql''. > > This commit adds the ``msoledbsql'' API to mingw-w64 -- the only OLE DB > data access solution supported and maintained by Microsoft now. > > To provide class/interface identifiers msoledbsql.h in this commit uses > the same technique as, for example, mingw-w64's sqloledb.h file, i.e. it > uses the `DBINITCONSTANTS` guard to define identifiers only in one > module. Original Microsoft's files (both msoledbsql.h from the new API > and sqloledb.h from Microsoft Windows 10 SDK) use > `__declspec(selectany)` to move that "burden" to the linker. > > [1]: https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/ > microsoft-is-aligning-with-odbc-for-native-relational-data-access/ > [2]: https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/ > announcing-the-new-release-of-ole-db-driver-for-sql-server/ > > Signed-off-by: Ruslan Garipov > --- > The patch looks good, but it does apply cleanly to the master branch. Please rebase this work against master, create another patch, then send it again. The x86 import library was absent. I have attached an (albeit untested) one, generated using 'gendef' from the x86 DLL. -- Best regards, LH_Mouse ; ; Definition file of msoledbsql.dll ; Automatic generated by gendef ; written by Kai Tietz 2008 ; LIBRARY "msoledbsql.dll" EXPORTS DllCanUnloadNow@0 DllGetClassObject@12 DllMain@12 DllRegisterServer@0 DllUnregisterServer@0 OpenSqlFilestream@24 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
