Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server

2019-02-28 Thread Ruslan Garipov
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] Broken FreeAddrInfoEx in ws2tcpip.h

2019-02-28 Thread Liu Hao
在 2019/2/11 下午6:34, Liu Hao 写道:
> 在 2019/2/8 19:59, Liu Hao 写道:
>> 在 2019/2/8 上午4:41, LRN 写道:
>>> ws2tcpip.h declares:
>>> WINSOCK_API_LINKAGE void WSAAPI FreeAddrInfoExA(PADDRINFOEXA pAddrInfo);
>>> WINSOCK_API_LINKAGE void WSAAPI FreeAddrInfoExW(PADDRINFOEXW pAddrInfo);
>>>
>>> however of these two functions only the latter exists in ws2_32.dll. The 
>>> former
>>> is actually named FreeAddrInfoEx, without the "A" suffix.
>>>
>>>
>>>
>>
>> We had better take look at how Microsoft people deal with this in their
>> header.
>>
>> I will take care of this a few days later, should nobody have proposed a
>> patch by then.
>>
>>
> 
> The patch attached should resolve this issue, but please read the commit
> message.

LRN, do you have any comments on this?  And on the removal of
`FreeAddrInfoExA`?


-- 
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 2/2] Ensure wait timeouts are respected

2019-02-28 Thread Liu Hao
在 2019/3/1 下午1:34, LRN 写道:
> On 01.03.2019 5:53, Liu Hao wrote:
> 
> GetTickCount64() then, i guess?
> 

`GetTIckCount64()` for Vista and above or `QueryPerformanceCounter()`
for XP. I really don't care about XP, since MSYS2 has officially dropped
XP support, but I think it might be configurable during build time by
always using `uint64_t` for timestamps and call `GetTickCount()` or the
64-bit variant depending on the value of `_WIN32_WINNT`.


-- 
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 2/2] Ensure wait timeouts are respected

2019-02-28 Thread LRN
On 01.03.2019 5:53, Liu Hao wrote:
> 在 2019/3/1 上午2:09, LRN 写道:
>> +unsigned long
>> +_pthread_wait_for_single_object (void *handle, unsigned long timeout)
>> +{
>> +  DWORD result;
>> +  BOOL end_loop;
>> +  DWORD start_time = GetTickCount ();
> 
> There is no need to invoke `GetTickCount()` if `timeout` is `INFINITE`
> or zero.
> 
> Also I don't recommend use of `GetTickCount()` because its 32-bit return
> value would wrap round in approximately 49 days.

GetTickCount64() then, i guess?

> 
>> +
>> +  if (timeout == INFINITE || timeout == 0)
>> +return WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
>> +
>> +  do
>> +  {
>> +result = WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
> 
> You have to recalculate `timeout` in this loop.

Ah, damn. Indeed.



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 1/2] Round up when converting nanoseconds to milliseconds

2019-02-28 Thread LRN
On 01.03.2019 5:48, Liu Hao wrote:
> 在 2019/3/1 上午2:09, LRN 写道:
>> If the caller provides ts_nsec in struct timespec,
>> we lose precision when converting that time to milliseconds
>> for our WaitFor*() calls. Make sure we round *up* when doing that
>> conversion, as otherwise the wait time will be *less* than the caller
>> expects. Users of pthreads on non-realtime systems are generally
>> OK with functions returning a bit later than requested. But timing out
>> *earlier* than the requested time is completely unexpected.
>> ---
>>  mingw-w64-libraries/winpthreads/src/misc.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>>
>>
> 
> This seems an overkill. There is a much simpler solution:
> 
> ```
> t += (unsigned long long) (ts->tv_nsec + 99) / 100;
> ```
> 
> 

I don't care how it works, as long as it works :)



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 2/2] Ensure wait timeouts are respected

2019-02-28 Thread Liu Hao
在 2019/3/1 上午2:09, LRN 写道:
> WaitFor*() functions may time out earlier than requested
> or later than requested. The "later" part is generally OK.
> The "earlier" part is not.
> 
> Fix this by running the wait functions in a loop until the
> time actually runs out, or the function returns a non-timeout
> code.
> 
> This does not apply to cases where timeout is 0 or INFINITE.
> Those still use plain WaitFor*() calls (the wrappers, obviously,
> still support these important corner-cases, but why call them
> when we know that the timeout is 0 or INFINITE?).
> 
> This wouldn't have worked for handles that auto-reset
> (i.e. where WaitFor*() call wakes up on handle activation, and immediately
> resets the handle, preventing further WaitFor*() calls from waking up
> until the handle is activated again), but winpthreads does not use those.
> 
> The timeout checker uses the coarse GetTickCount() because it's fast.
> Though it might not be accurate enough, let's go with it first.
> ---



> +unsigned long
> +_pthread_wait_for_single_object (void *handle, unsigned long timeout)
> +{
> +  DWORD result;
> +  BOOL end_loop;
> +  DWORD start_time = GetTickCount ();

There is no need to invoke `GetTickCount()` if `timeout` is `INFINITE`
or zero.

Also I don't recommend use of `GetTickCount()` because its 32-bit return
value would wrap round in approximately 49 days.

> +
> +  if (timeout == INFINITE || timeout == 0)
> +return WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
> +
> +  do
> +  {
> +result = WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);

You have to recalculate `timeout` in this loop.

> +end_loop = (GetTickCount () - start_time >= timeout);
> +  } while (!end_loop && result == WAIT_TIMEOUT);
> +
> +  return result;
> +}




-- 
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 1/2] Round up when converting nanoseconds to milliseconds

2019-02-28 Thread Liu Hao
在 2019/3/1 上午2:09, LRN 写道:
> If the caller provides ts_nsec in struct timespec,
> we lose precision when converting that time to milliseconds
> for our WaitFor*() calls. Make sure we round *up* when doing that
> conversion, as otherwise the wait time will be *less* than the caller
> expects. Users of pthreads on non-realtime systems are generally
> OK with functions returning a bit later than requested. But timing out
> *earlier* than the requested time is completely unexpected.
> ---
>  mingw-w64-libraries/winpthreads/src/misc.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> 
> 

This seems an overkill. There is a much simpler solution:

```
t += (unsigned long long) (ts->tv_nsec + 99) / 100;
```


-- 
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

2019-02-28 Thread Liu Hao
在 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] Remove support for --disable-secure-api.

2019-02-28 Thread JonY via Mingw-w64-public
On 2/28/19 8:23 PM, Martin Storsjö wrote:
> On Thu, 28 Feb 2019, Liu Hao wrote:
> 
>> 在 2019/2/28 22:57, Jacek Caban 写道:
>>> It could be useful a long time ago for avoiding using APIs that were new
>>> and not always present back then. Also, back then, most compatibility
>>> functions that we have now were missing. I don't see a point in
>>> supporting it any more.
>>>
>>>
>>> Signed-off-by: Jacek Caban 
>>> ---
>>>
>>
>> I have no objection on removal of it. However I would like to hear about
>> other's opinions.
> 
> Sounds sensible to me. I presume that passing --enable-secure-api to
> configure will just give a harmless warning and won't break the build
> for everybody out there?
> 

I have no problems with its removal.



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 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

2019-02-28 Thread Martin Storsjö

On Thu, 28 Feb 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-headers/crt/corecrt_wstdlib.h  | 39 
mingw-w64-headers/crt/sec_api/stdlib_s.h | 22 -
mingw-w64-headers/crt/sec_api/wchar_s.h  | 34 -
mingw-w64-headers/crt/stdlib.h   |  3 +-
mingw-w64-headers/crt/wchar.h|  3 +-
5 files changed, 43 insertions(+), 58 deletions(-)
create mode 100644 mingw-w64-headers/crt/corecrt_wstdlib.h


Both patches sound sensible to me.

// Martin



___
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] Remove support for --disable-secure-api.

2019-02-28 Thread Martin Storsjö

On Thu, 28 Feb 2019, Liu Hao wrote:


在 2019/2/28 22:57, Jacek Caban 写道:

It could be useful a long time ago for avoiding using APIs that were new
and not always present back then. Also, back then, most compatibility
functions that we have now were missing. I don't see a point in
supporting it any more.


Signed-off-by: Jacek Caban 
---



I have no objection on removal of it. However I would like to hear about
other's opinions.


Sounds sensible to me. I presume that passing --enable-secure-api to 
configure will just give a harmless warning and won't break the build for 
everybody out there?


// Martin

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] [PATCH 1/2] Round up when converting nanoseconds to milliseconds

2019-02-28 Thread LRN
If the caller provides ts_nsec in struct timespec,
we lose precision when converting that time to milliseconds
for our WaitFor*() calls. Make sure we round *up* when doing that
conversion, as otherwise the wait time will be *less* than the caller
expects. Users of pthreads on non-realtime systems are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
---
 mingw-w64-libraries/winpthreads/src/misc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

From 46ae81988f8ae040380816968f825a98af686def Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:49:49 +
Subject: [PATCH 1/2] Round up when converting nanoseconds to milliseconds

If the caller provides ts_nsec in struct timespec,
we lose precision when converting that time to milliseconds
for our WaitFor*() calls. Make sure we round *up* when doing that
conversion, as otherwise the wait time will be *less* than the caller
expects. Users of pthreads on non-realtime systems are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
---
 mingw-w64-libraries/winpthreads/src/misc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index ab0488c..ddc5ab9 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -24,6 +24,9 @@
 #include "windows.h"
 #include "misc.h"
 
+#define NSEC_PER_SEC 10ULL
+#define NSEC_PER_MSEC   100ULL
+
 unsigned long long _pthread_time_in_ms(void)
 {
 FILETIME ft;
@@ -35,8 +38,16 @@ unsigned long long _pthread_time_in_ms(void)
 
 unsigned long long _pthread_time_in_ms_from_timespec(const struct timespec *ts)
 {
+unsigned long long t_ns;
 unsigned long long t = (unsigned long long) ts->tv_sec * 1000LL;
-t += (unsigned long long) (ts->tv_nsec / 100);
+t += (unsigned long long) (ts->tv_nsec / NSEC_PER_MSEC);
+
+t_ns = NSEC_PER_SEC * (unsigned long long) ts->tv_sec;
+t_ns += (unsigned long long) ts->tv_nsec;
+
+/* Round up when converting nanoseconds to milliseconds */
+if (t * NSEC_PER_MSEC < t_ns)
+  t += 1;
 
 return t;
 }
-- 
2.4.0



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


[Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

2019-02-28 Thread LRN
WaitFor*() functions may time out earlier than requested
or later than requested. The "later" part is generally OK.
The "earlier" part is not.

Fix this by running the wait functions in a loop until the
time actually runs out, or the function returns a non-timeout
code.

This does not apply to cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount() because it's fast.
Though it might not be accurate enough, let's go with it first.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |  8 ++---
 mingw-w64-libraries/winpthreads/src/misc.c   | 51 
 mingw-w64-libraries/winpthreads/src/misc.h   |  2 ++
 mingw-w64-libraries/winpthreads/src/mutex.c  |  2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |  4 +--
 5 files changed, 60 insertions(+), 7 deletions(-)

From 8ef33231341c47ff6ca060e00c3c8be494a986b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:55:08 +
Subject: [PATCH 2/2] Ensure wait timeouts are respected

WaitFor*() functions may time out earlier than requested
or later than requested. The "later" part is generally OK.
The "earlier" part is not.

Fix this by running the wait functions in a loop until the
time actually runs out, or the function returns a non-timeout
code.

This does not apply to cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount() because it's fast.
Though it might not be accurate enough, let's go with it first.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |  8 ++---
 mingw-w64-libraries/winpthreads/src/misc.c   | 51 
 mingw-w64-libraries/winpthreads/src/misc.h   |  2 ++
 mingw-w64-libraries/winpthreads/src/mutex.c  |  2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |  4 +--
 5 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/cond.c 
b/mingw-w64-libraries/winpthreads/src/cond.c
index 3754a56..368ee8a 100644
--- a/mingw-w64-libraries/winpthreads/src/cond.c
+++ b/mingw-w64-libraries/winpthreads/src/cond.c
@@ -598,7 +598,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   DWORD res, dt;
   if (nointerrupt == 1)
   {
-res = WaitForSingleObject(sema, timeout);
+res = _pthread_wait_for_single_object(sema, timeout);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
@@ -622,7 +622,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   if (maxH == 2)
   {
 redo:
-  res = WaitForMultipleObjects(maxH, arr, 0, timeout);
+  res = _pthread_wait_for_multiple_objects(maxH, arr, 0, timeout);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -655,7 +655,7 @@ redo:
   if (timeout == INFINITE)
   {
 do {
-  res = WaitForSingleObject(sema, 40);
+  res = _pthread_wait_for_single_object(sema, 40);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -684,7 +684,7 @@ redo:
   dt = 20;
   do {
 if (dt > timeout) dt = timeout;
-res = WaitForSingleObject(sema, dt);
+res = _pthread_wait_for_single_object(sema, dt);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index ddc5ab9..13e309d 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -62,3 +62,54 @@ unsigned long long _pthread_rel_time_in_ms(const struct 
timespec *ts)
 return t1 - t2;
 }
 
+/* A wrapper around WaitForSingleObject() that ensures that
+ * the wait function does not time out before the time
+ * actually runs out. This is needed because WaitForSingleObject()
+ * might have poor accuracy, returning earlier than expected.
+ * On the other hand, returning a bit *later* than expected
+ * is acceptable in a preemptive multitasking environment.
+ */
+unsigned long
+_pthread_wait_for_single_object (void *handle, unsigned long 

[Mingw-w64-public] [PATCH 1/2] corecrt.h: Add new file and move declaration from crtdefs.h there.

2019-02-28 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/crt/corecrt.h | 485 
 mingw-w64-headers/crt/crtdefs.h | 475 +--
 2 files changed, 486 insertions(+), 474 deletions(-)
 create mode 100644 mingw-w64-headers/crt/corecrt.h


diff --git a/mingw-w64-headers/crt/corecrt.h b/mingw-w64-headers/crt/corecrt.h
new file mode 100644
index ..d171a013
--- /dev/null
+++ b/mingw-w64-headers/crt/corecrt.h
@@ -0,0 +1,485 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifndef _INC_CORECRT
+#define _INC_CORECRT
+
+#include <_mingw.h>
+
+#ifndef __WIDL__
+#undef _CRT_PACKING
+#define _CRT_PACKING 8
+#pragma pack(push,_CRT_PACKING)
+#endif
+
+#ifdef __ERRCODE_DEFINED_MS
+/* #define __ERRCODE_DEFINED_MS */
+typedef int errcode;
+#endif
+
+#ifndef _CRTNOALIAS
+#define _CRTNOALIAS
+#endif
+
+#ifndef _CRTRESTRICT
+#define _CRTRESTRICT
+#endif
+
+#ifndef _SIZE_T_DEFINED
+#define _SIZE_T_DEFINED
+#undef size_t
+#ifdef _WIN64
+__MINGW_EXTENSION typedef unsigned __int64 size_t;
+#else
+typedef unsigned int size_t;
+#endif /* _WIN64 */
+#endif /* _SIZE_T_DEFINED */
+
+#ifndef _SSIZE_T_DEFINED
+#define _SSIZE_T_DEFINED
+#undef ssize_t
+#ifdef _WIN64
+__MINGW_EXTENSION typedef __int64 ssize_t;
+#else
+typedef int ssize_t;
+#endif /* _WIN64 */
+#endif /* _SSIZE_T_DEFINED */
+
+#ifndef _RSIZE_T_DEFINED
+typedef size_t rsize_t;
+#define _RSIZE_T_DEFINED
+#endif
+
+#ifndef _INTPTR_T_DEFINED
+#define _INTPTR_T_DEFINED
+#ifndef __intptr_t_defined
+#define __intptr_t_defined
+#undef intptr_t
+#ifdef _WIN64
+__MINGW_EXTENSION typedef __int64 intptr_t;
+#else
+typedef int intptr_t;
+#endif /* _WIN64 */
+#endif /* __intptr_t_defined */
+#endif /* _INTPTR_T_DEFINED */
+
+#ifndef _UINTPTR_T_DEFINED
+#define _UINTPTR_T_DEFINED
+#ifndef __uintptr_t_defined
+#define __uintptr_t_defined
+#undef uintptr_t
+#ifdef _WIN64
+__MINGW_EXTENSION typedef unsigned __int64 uintptr_t;
+#else
+typedef unsigned int uintptr_t;
+#endif /* _WIN64 */
+#endif /* __uintptr_t_defined */
+#endif /* _UINTPTR_T_DEFINED */
+
+#ifndef _PTRDIFF_T_DEFINED
+#define _PTRDIFF_T_DEFINED
+#ifndef _PTRDIFF_T_
+#define _PTRDIFF_T_
+#undef ptrdiff_t
+#ifdef _WIN64
+__MINGW_EXTENSION typedef __int64 ptrdiff_t;
+#else
+typedef int ptrdiff_t;
+#endif /* _WIN64 */
+#endif /* _PTRDIFF_T_ */
+#endif /* _PTRDIFF_T_DEFINED */
+
+#ifndef _WCHAR_T_DEFINED
+#define _WCHAR_T_DEFINED
+#if !defined(__cplusplus) && !defined(__WIDL__)
+typedef unsigned short wchar_t;
+#endif /* C++ */
+#endif /* _WCHAR_T_DEFINED */
+
+#ifndef _WCTYPE_T_DEFINED
+#define _WCTYPE_T_DEFINED
+#ifndef _WINT_T
+#define _WINT_T
+typedef unsigned short wint_t;
+typedef unsigned short wctype_t;
+#endif /* _WINT_T */
+#endif /* _WCTYPE_T_DEFINED */
+
+#ifndef _ERRCODE_DEFINED
+#define _ERRCODE_DEFINED
+typedef int errno_t;
+#endif
+
+#ifndef _TIME32_T_DEFINED
+#define _TIME32_T_DEFINED
+typedef long __time32_t;
+#endif
+
+#ifndef _TIME64_T_DEFINED
+#define _TIME64_T_DEFINED
+__MINGW_EXTENSION typedef __int64 __time64_t;
+#endif /* _TIME64_T_DEFINED */
+
+#ifdef _USE_32BIT_TIME_T
+#ifdef _WIN64
+#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
+#undef _USE_32BIT_TIME_T
+#endif
+#endif /* _USE_32BIT_TIME_T */
+
+#ifndef _TIME_T_DEFINED
+#define _TIME_T_DEFINED
+#ifdef _USE_32BIT_TIME_T
+typedef __time32_t time_t;
+#else
+typedef __time64_t time_t;
+#endif
+#endif /* _TIME_T_DEFINED */
+
+#ifndef _CRT_SECURE_CPP_NOTHROW
+#define _CRT_SECURE_CPP_NOTHROW throw()
+#endif
+
+#if defined(__cplusplus) && _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES
+
+#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(__ret,__func,__dsttype,__dst) \
+  extern "C++" { \
+template  \
+inline __ret __cdecl __func(__dsttype (&__dst)[__size]) { \
+return __func(__dst,__size); \
+} \
+  }
+
+#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(__ret,__func,__dsttype,__dst,__type1,__arg1) \
+  extern "C++" {\
+template  \
+inline __ret __cdecl __func(__dsttype (&__dst)[__size], __type1 __arg1) { \
+return __func(__dst,__size,__arg1);  \
+}\
+  }
+
+#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(__ret,__func,__dsttype,__dst,__type1,__arg1,__type2,__arg2)\
+  extern "C++" {\
+template  inline\
+__ret __cdecl __func(__dsttype (&__dst)[__size], __type1 __arg1, __type2 __arg2) { \
+return __func(__dst,__size,__arg1,__arg2);  \
+}\
+  }
+
+#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(__ret,__func,__dsttype,__dst,__type1,__arg1,__type2,__arg2,__type3,__arg3) \
+  extern "C++" { \
+template  inline \
+__ret __cdecl __func(__dsttype (&__dst)[__size], __type1 __arg1, __type2 __arg2, __type3 __arg3) { \
+return __func(__dst,__size,__arg1,__arg2,__arg3); \
+}\
+  }
+
+#define 

[Mingw-w64-public] [PATCH 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

2019-02-28 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/crt/corecrt_wstdlib.h  | 39 
 mingw-w64-headers/crt/sec_api/stdlib_s.h | 22 -
 mingw-w64-headers/crt/sec_api/wchar_s.h  | 34 -
 mingw-w64-headers/crt/stdlib.h   |  3 +-
 mingw-w64-headers/crt/wchar.h|  3 +-
 5 files changed, 43 insertions(+), 58 deletions(-)
 create mode 100644 mingw-w64-headers/crt/corecrt_wstdlib.h


diff --git a/mingw-w64-headers/crt/corecrt_wstdlib.h b/mingw-w64-headers/crt/corecrt_wstdlib.h
new file mode 100644
index ..d8a0e5da
--- /dev/null
+++ b/mingw-w64-headers/crt/corecrt_wstdlib.h
@@ -0,0 +1,39 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#ifndef _INC_CORECRT_WSTDLIB
+#define _INC_CORECRT_WSTDLIB
+
+#include 
+
+  _CRTIMP errno_t __cdecl _itow_s (int _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_itow_s,int,_Val,wchar_t,_DstBuf,int,_Radix)
+
+  _CRTIMP errno_t __cdecl _ltow_s (long _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ltow_s,long,_Val,wchar_t,_DstBuf,int,_Radix)
+
+  _CRTIMP errno_t __cdecl _ultow_s (unsigned long _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ultow_s,unsigned long,_Val,wchar_t,_DstBuf,int,_Radix)
+
+  _CRTIMP errno_t __cdecl _wgetenv_s(size_t *_ReturnSize,wchar_t *_DstBuf,size_t _DstSizeInWords,const wchar_t *_VarName);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_wgetenv_s,size_t*,_ReturnSize,wchar_t,_DstBuf,const wchar_t*,_VarName)
+
+  _CRTIMP errno_t __cdecl _wdupenv_s(wchar_t **_Buffer,size_t *_BufferSizeInWords,const wchar_t *_VarName);
+  _CRTIMP errno_t __cdecl _i64tow_s(__int64 _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
+  _CRTIMP errno_t __cdecl _ui64tow_s(unsigned __int64 _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
+
+  _CRTIMP errno_t __cdecl _wmakepath_s(wchar_t *_PathResult,size_t _SizeInWords,const wchar_t *_Drive,const wchar_t *_Dir,const wchar_t *_Filename,const wchar_t *_Ext);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_4(errno_t,_wmakepath_s,wchar_t,_PathResult,const wchar_t*,_Drive,const wchar_t*,_Dir,const wchar_t*,_Filename,const wchar_t*,_Ext)
+
+  _CRTIMP errno_t __cdecl _wputenv_s(const wchar_t *_Name,const wchar_t *_Value);
+
+  _CRTIMP errno_t __cdecl _wsearchenv_s(const wchar_t *_Filename,const wchar_t *_EnvVar,wchar_t *_ResultPath,size_t _SizeInWords);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_2_0(errno_t,_wsearchenv_s,const wchar_t*,_Filename,const wchar_t*,_EnvVar,wchar_t,_ResultPath)
+
+  _CRTIMP errno_t __cdecl _wsplitpath_s(const wchar_t *_FullPath,wchar_t *_Drive,size_t _DriveSizeInWords,wchar_t *_Dir,size_t _DirSizeInWords,wchar_t *_Filename,size_t _FilenameSizeInWords,wchar_t *_Ext,size_t _ExtSizeInWords);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_SPLITPATH(errno_t,_wsplitpath_s,wchar_t,_Dest)
+
+#endif /* _INC_CORECRT_WSTDLIB */
+
diff --git a/mingw-w64-headers/crt/sec_api/stdlib_s.h b/mingw-w64-headers/crt/sec_api/stdlib_s.h
index 94e62a33..02117b46 100644
--- a/mingw-w64-headers/crt/sec_api/stdlib_s.h
+++ b/mingw-w64-headers/crt/sec_api/stdlib_s.h
@@ -25,17 +25,6 @@ extern "C" {
   _CRTIMP errno_t __cdecl wcstombs_s(size_t *_PtNumOfCharConverted,char *_Dst,size_t _DstSizeInBytes,const wchar_t *_Src,size_t _MaxCountInBytes);
   _CRTIMP errno_t __cdecl _wcstombs_s_l(size_t *_PtNumOfCharConverted,char *_Dst,size_t _DstSizeInBytes,const wchar_t *_Src,size_t _MaxCountInBytes,_locale_t _Locale);
 
-#ifndef _WSTDLIB_S_DEFINED
-#define _WSTDLIB_S_DEFINED
-  _CRTIMP errno_t __cdecl _itow_s (int _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
-  _CRTIMP errno_t __cdecl _ltow_s (long _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
-  _CRTIMP errno_t __cdecl _ultow_s (unsigned long _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
-  _CRTIMP errno_t __cdecl _wgetenv_s(size_t *_ReturnSize,wchar_t *_DstBuf,size_t _DstSizeInWords,const wchar_t *_VarName);
-  _CRTIMP errno_t __cdecl _wdupenv_s(wchar_t **_Buffer,size_t *_BufferSizeInWords,const wchar_t *_VarName);
-  _CRTIMP errno_t __cdecl _i64tow_s(__int64 _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
-  _CRTIMP errno_t __cdecl _ui64tow_s(unsigned __int64 _Val,wchar_t *_DstBuf,size_t _SizeInWords,int _Radix);
-#endif
-
 #ifndef _POSIX_
   _CRTIMP errno_t __cdecl _ecvt_s(char *_DstBuf,size_t _Size,double _Val,int _NumOfDights,int *_PtDec,int *_PtSign);
   _CRTIMP errno_t __cdecl _fcvt_s(char *_DstBuf,size_t _Size,double _Val,int _NumOfDec,int *_PtDec,int *_PtSign);
@@ -47,17 +36,6 @@ extern "C" {
   _CRTIMP errno_t __cdecl _splitpath_s(const char *_FullPath,char *_Drive,size_t _DriveSize,char *_Dir,size_t _DirSize,char *_Filename,size_t _FilenameSize,char 

Re: [Mingw-w64-public] [PATCH] Add Microsoft OLE DB driver for SQL server

2019-02-28 Thread Ruslan Garipov
> 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] Remove support for --disable-secure-api.

2019-02-28 Thread Liu Hao
在 2019/2/28 22:57, Jacek Caban 写道:
> It could be useful a long time ago for avoiding using APIs that were new
> and not always present back then. Also, back then, most compatibility
> functions that we have now were missing. I don't see a point in
> supporting it any more.
> 
> 
> Signed-off-by: Jacek Caban 
> ---
> 

I have no objection on removal of it. However I would like to hear about
other's opinions.


-- 
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


[Mingw-w64-public] [PATCH] Remove support for --disable-secure-api.

2019-02-28 Thread Jacek Caban
It could be useful a long time ago for avoiding using APIs that were new 
and not always present back then. Also, back then, most compatibility 
functions that we have now were missing. I don't see a point in 
supporting it any more.



Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/secapi/_cgets_s.c |  1 -
 mingw-w64-crt/secapi/_cgetws_s.c|  1 -
 mingw-w64-crt/secapi/_cprintf_s.c   |  1 -
 mingw-w64-crt/secapi/_cprintf_s_l.c |  1 -
 mingw-w64-crt/secapi/_cwprintf_s.c  |  1 -
 mingw-w64-crt/secapi/_cwprintf_s_l.c|  1 -
 mingw-w64-crt/secapi/_vcprintf_s.c  |  1 -
 mingw-w64-crt/secapi/_vcprintf_s_l.c|  1 -
 mingw-w64-crt/secapi/_vcwprintf_s.c |  1 -
 mingw-w64-crt/secapi/_vcwprintf_s_l.c   |  1 -
 mingw-w64-crt/secapi/_vscprintf_p.c |  1 -
 mingw-w64-crt/secapi/_vscwprintf_p.c|  1 -
 mingw-w64-crt/secapi/_vswprintf_p.c |  1 -
 mingw-w64-crt/secapi/_waccess_s.c   |  1 -
 mingw-w64-crt/secapi/_wmktemp_s.c   |  1 -
 mingw-w64-crt/secapi/memmove_s.c|  1 -
 mingw-w64-crt/secapi/sprintf_s.c|  1 -
 mingw-w64-crt/secapi/strerror_s.c   |  1 -
 mingw-w64-crt/secapi/vsprintf_s.c   |  1 -
 mingw-w64-crt/secapi/wmemcpy_s.c|  1 -
 mingw-w64-crt/secapi/wmemmove_s.c   |  1 -
 mingw-w64-headers/configure.ac  | 12 
 mingw-w64-headers/crt/_mingw.h.in   |  9 +
 mingw-w64-headers/crt/_mingw_secapi.h   |  4 ++--
 mingw-w64-headers/crt/sec_api/conio_s.h |  3 ---
 mingw-w64-headers/crt/sec_api/crtdbg_s.h|  4 
 mingw-w64-headers/crt/sec_api/mbstring_s.h  |  3 ---
 mingw-w64-headers/crt/sec_api/search_s.h|  3 ---
 mingw-w64-headers/crt/sec_api/stdio_s.h |  3 ---
 mingw-w64-headers/crt/sec_api/stdlib_s.h|  3 ---
 mingw-w64-headers/crt/sec_api/stralign_s.h  |  3 ---
 mingw-w64-headers/crt/sec_api/string_s.h|  3 ---
 mingw-w64-headers/crt/sec_api/sys/timeb_s.h |  3 ---
 mingw-w64-headers/crt/sec_api/tchar_s.h |  3 ---
 mingw-w64-headers/crt/sec_api/wchar_s.h |  3 ---
 35 files changed, 7 insertions(+), 73 deletions(-)


diff --git a/mingw-w64-crt/secapi/_cgets_s.c b/mingw-w64-crt/secapi/_cgets_s.c
index e70efe72..f81623a9 100644
--- a/mingw-w64-crt/secapi/_cgets_s.c
+++ b/mingw-w64-crt/secapi/_cgets_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_cgetws_s.c b/mingw-w64-crt/secapi/_cgetws_s.c
index dff41870..01ee3d1b 100644
--- a/mingw-w64-crt/secapi/_cgetws_s.c
+++ b/mingw-w64-crt/secapi/_cgetws_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_cprintf_s.c b/mingw-w64-crt/secapi/_cprintf_s.c
index 36ea582d..eef77df4 100644
--- a/mingw-w64-crt/secapi/_cprintf_s.c
+++ b/mingw-w64-crt/secapi/_cprintf_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_cprintf_s_l.c b/mingw-w64-crt/secapi/_cprintf_s_l.c
index 316ca86e..cce1d51b 100644
--- a/mingw-w64-crt/secapi/_cprintf_s_l.c
+++ b/mingw-w64-crt/secapi/_cprintf_s_l.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_cwprintf_s.c b/mingw-w64-crt/secapi/_cwprintf_s.c
index b5ce0ab9..013ccc47 100644
--- a/mingw-w64-crt/secapi/_cwprintf_s.c
+++ b/mingw-w64-crt/secapi/_cwprintf_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_cwprintf_s_l.c b/mingw-w64-crt/secapi/_cwprintf_s_l.c
index cadd55d0..50c9c4ba 100644
--- a/mingw-w64-crt/secapi/_cwprintf_s_l.c
+++ b/mingw-w64-crt/secapi/_cwprintf_s_l.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_vcprintf_s.c b/mingw-w64-crt/secapi/_vcprintf_s.c
index b512bb21..91f143f1 100644
--- a/mingw-w64-crt/secapi/_vcprintf_s.c
+++ b/mingw-w64-crt/secapi/_vcprintf_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_vcprintf_s_l.c b/mingw-w64-crt/secapi/_vcprintf_s_l.c
index e4c86ceb..787c76be 100644
--- a/mingw-w64-crt/secapi/_vcprintf_s_l.c
+++ b/mingw-w64-crt/secapi/_vcprintf_s_l.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_vcwprintf_s.c b/mingw-w64-crt/secapi/_vcwprintf_s.c
index e6badb1e..325e8661 100644
--- a/mingw-w64-crt/secapi/_vcwprintf_s.c
+++ b/mingw-w64-crt/secapi/_vcwprintf_s.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
diff --git a/mingw-w64-crt/secapi/_vcwprintf_s_l.c b/mingw-w64-crt/secapi/_vcwprintf_s_l.c
index 2ce1deff..4d112a1c 100644
--- a/mingw-w64-crt/secapi/_vcwprintf_s_l.c
+++ b/mingw-w64-crt/secapi/_vcwprintf_s_l.c
@@ -1,4 +1,3 @@
-#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 

Re: [Mingw-w64-public] [PATCH] string_s.h: Add some missing C++ overloads.

2019-02-28 Thread Liu Hao
在 2019/2/28 22:39, Jacek Caban 写道:
> Signed-off-by: Jacek Caban 
> ---
>  mingw-w64-headers/crt/sec_api/string_s.h | 4 
>  mingw-w64-headers/crt/sec_api/wchar_s.h  | 4 
>  2 files changed, 8 insertions(+)
> 
> 

This patch looks good to me.
-- 
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


[Mingw-w64-public] [PATCH] string_s.h: Add some missing C++ overloads.

2019-02-28 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/crt/sec_api/string_s.h | 4 
 mingw-w64-headers/crt/sec_api/wchar_s.h  | 4 
 2 files changed, 8 insertions(+)


diff --git a/mingw-w64-headers/crt/sec_api/string_s.h b/mingw-w64-headers/crt/sec_api/string_s.h
index 42000fb8..b230983f 100644
--- a/mingw-w64-headers/crt/sec_api/string_s.h
+++ b/mingw-w64-headers/crt/sec_api/string_s.h
@@ -54,9 +54,13 @@ extern "C" {
   _CRTIMP errno_t __cdecl _wcsnset_s(wchar_t *_Dst,size_t _DstSizeInWords,wchar_t _Val,size_t _MaxCount);
   _CRTIMP errno_t __cdecl _wcsset_s(wchar_t *_Str,size_t _SizeInWords,wchar_t _Val);
   _CRTIMP errno_t __cdecl _wcslwr_s(wchar_t *_Str,size_t _SizeInWords);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _wcslwr_s, wchar_t, _Str)
   _CRTIMP errno_t __cdecl _wcslwr_s_l(wchar_t *_Str,size_t _SizeInWords,_locale_t _Locale);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, _wcslwr_s_l, wchar_t, _Str, _locale_t, _Locale)
   _CRTIMP errno_t __cdecl _wcsupr_s(wchar_t *_Str,size_t _Size);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _wcsupr_s, wchar_t, _Str)
   _CRTIMP errno_t __cdecl _wcsupr_s_l(wchar_t *_Str,size_t _Size,_locale_t _Locale);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, _wcsupr_s_l, wchar_t, _Str, _locale_t, _Locale)
 
   _CRTIMP errno_t __cdecl wcscpy_s(wchar_t *_Dst, rsize_t _SizeInWords, const wchar_t *_Src);
   __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, wcscpy_s, wchar_t, _Dest, const wchar_t *, _Source)
diff --git a/mingw-w64-headers/crt/sec_api/wchar_s.h b/mingw-w64-headers/crt/sec_api/wchar_s.h
index c36c4bbf..74d40df5 100644
--- a/mingw-w64-headers/crt/sec_api/wchar_s.h
+++ b/mingw-w64-headers/crt/sec_api/wchar_s.h
@@ -312,9 +312,13 @@ extern "C" {
   _CRTIMP errno_t __cdecl _wcsnset_s(wchar_t *_Dst,size_t _DstSizeInWords,wchar_t _Val,size_t _MaxCount);
   _CRTIMP errno_t __cdecl _wcsset_s(wchar_t *_Str,size_t _SizeInWords,wchar_t _Val);
   _CRTIMP errno_t __cdecl _wcslwr_s(wchar_t *_Str,size_t _SizeInWords);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _wcslwr_s, wchar_t, _Str)
   _CRTIMP errno_t __cdecl _wcslwr_s_l(wchar_t *_Str,size_t _SizeInWords,_locale_t _Locale);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, _wcslwr_s_l, wchar_t, _Str, _locale_t, _Locale)
   _CRTIMP errno_t __cdecl _wcsupr_s(wchar_t *_Str,size_t _Size);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _wcsupr_s, wchar_t, _Str)
   _CRTIMP errno_t __cdecl _wcsupr_s_l(wchar_t *_Str,size_t _Size,_locale_t _Locale);
+  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, _wcsupr_s_l, wchar_t, _Str, _locale_t, _Locale)
 
   _CRTIMP errno_t __cdecl wcscat_s(wchar_t *_Dst, rsize_t _DstSize, const wchar_t *_Src);
   __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, wcscat_s, wchar_t, _Dest, const wchar_t *, _Source)

___
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-02-28 Thread Liu Hao
在 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

2019-02-28 Thread 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:

```
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:

```