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;
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
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 +-
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 am not familiar with CC. Perhaps it is just a symlink to GCC
Yes, cc is a soft link to gcc. I just got into the habit of using CC,
not GCC. Therefore, the problem I wanted to show you in my previous
message is that GCC for Microsoft Windows can't compile the sample with
two structures
在 2019/2/28 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:
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
在 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
在 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
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 -
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
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
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
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
在 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
在 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
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
在 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
在 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
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
在 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
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
22 matches
Mail list logo
