Re: [PATCH] ISO C 11 threads implementation

Hi Paul, I wrote: > You can go a long way with . ... > The use of is very similar to the use of . In fact, it should be possible to reuse the bulk of the and gnulib 'threads'/'lock'/... modules to provide an implementation of the essential API on native Windows (both mingw and MSVC). Whereas

Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I agree. There's a limitation bad enough for me to consider it a bug > in curre

argmatch: fix compilation errors

Hi Akim, My weekly continuous-integration test fails. These are the compilation errors: In file included from test-argmatch.c:22:0: test-argmatch.c: In function 'argmatch_backup_usage': ../gllib/argmatch.h:284:52: error: 'INT_MAX' undeclared (first use in this function) const int screen_wi

Re: include when needed

Nice. Thank you.

Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

Pip Cet wrote: > My suggestion would be "Assume that R always holds. This lets the > compiler optimize accordingly. Behavior is undefined if R is false, > fails to evaluate, or has side effects. Performance will suffer if R > contains function calls that are not inlined at compile time." I like

Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

On Sat, Jun 29, 2019 at 10:31 AM Bruno Haible wrote: > Pip Cet wrote: > > I would like to state that the current assume does > > behave very badly when combined with -fno-inline-small-functions > > -fno-inline. > > Since we can't address this limitation through an acceptable change > to the 'assum

include when needed

I got warnings about a missing #include in windows-tls.c. Some other files also need , and it should better be done explicitly rather than implicitly or by accident. 2019-06-30 Bruno Haible Include when needed. * lib/areadlinkat.c: Include , needed for free() in at-func.c.

inet_ntop, inet_pton: avoid conflict with native Windows functions

Another possible conflict between the Windows inet_ntop, inet_pton functions and the gnulib ones is at the source code level: When a compilation unit includes first and then (with _WIN32_WINNT >= 0x0600), there would be conflicting declarations of the rpl_inet_ntop or rpl_inet_ntop functions. T

inet_ntop, inet_pton: forward-compatibility with newer Windows versions

The functions inet_ntop and inet_pton exist in Windows Vista or newer: https://docs.microsoft.com/en-us/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inet_ntop https://docs.microsoft.com/en-us/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inet_pton So far, gnulib tests whether they are declared. Which, on m

inet_pton: fix link error on mingw with _WIN32_WINNT >= 0x0600

A testdir of module 'poll', when compiled on mingw with -D_WIN32_WINNT=0x0600, produces a link error: testd-bind.c:42: undefined reference to `rpl_inet_pton' The reason is that the file inet_pton.c, which contains the definition of rpl_inet_pton, was not compiled. This patch fixes it. 2019-06-3

poll: add comment

2019-06-30 Bruno Haible poll: Add comment. * lib/poll.c: Add comment about WSAPoll. diff --git a/lib/poll.c b/lib/poll.c index f6de24c..5d9150c 100644 --- a/lib/poll.c +++ b/lib/poll.c @@ -76,6 +76,13 @@ #ifdef WINDOWS_NATIVE +/* Do *not* use the function WSAPoll +

Re: modules poll* fail on mingw-w64 for i686 and x86_64

Hannes Müller wrote: > In file included from poll.c:39: > C:/Users/hm/Documents/msys32/mingw32/i686-w64- > mingw32/include/winsock2.h:1155:16: error: redefinition of 'struct > pollfd' > 1155 | typedef struct pollfd { > |^~ > In file included from poll.c:32: > ./poll.h:506

Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

On Sat, Jun 29, 2019 at 5:31 PM Paul Eggert wrote: > >> This is not a valid use of 'assume'. It's documented that assume's argument > >> should be free of side effects. > > > > But the compiler makes no such assumption > > Sure, but if the caller uses 'assume' contrary to its documentation, that's