Re: buy into mingw winpthreads?

[LRN]

On 18.05.2019 16:07, Bruno Haible wrote:
> Opinions?

I don't use gnulib much, but as far as threads are concerned:

Applications can use Windows threading APIs, if they need limited threading
support and know exactly what they want, and if the developers know how to use
Windows API correctly.

Portable libraries and frameworks are better with a full pthreads compatibility
library (unless the threading interface that they provide to other applications
does not resemble pthreads *at all*). Because if they try to implement a
POSIX-resembling threading-related API based on Windows thread API, they might
just end up re-implementing their own version of winpthreads, which is a waste
of time.



signature.asc
Description: OpenPGP digital signature

Re: isatty: make it return true in Cygwin consoles on native Windows

[LRN]

On 15.03.2019 22:42, Bruno Haible wrote:
> Gisle Vanem asked:
>>> I prefer to avoid the ntdll.dll API when possible.
>>
>> Okay, what's wrong with that?
> 
> 1) It's a violation of abstraction.
> 
> 2) The code you pointed to uses the function NtQueryObject. However, the
>Microsoft documentation
>
> 
>states "This function may be changed or removed from Windows without
>further notice."
> 
> 3) Probably code will run better on ReactOS or WINE if they don't use the
>lower layers.
> 
Advanced functionality sometimes requires the use of kernel API in cases where
Microsoft decided not to expose some NT kernel functions to applications in
Win32 API. These situations happen from time to time when dealing with 
portability.

You can lessen the impact by configure-time-testing the kernel APIs to ensure
that they are available and behave as expected. In some sense this is kind of
like using very Linux-specific functions. If the functions vanish, you'll
notice. Also ReactOS and WINE won't use that code, if they have no functions
and thus fail the configure-tests.

Either way, some things cannot be implemented in a clear and/or performant way
without these.



signature.asc
Description: OpenPGP digital signature

Re: [RFC] Adding a real HashTable implementation to gnulib

[LRN]

On 02.12.2018 16:41, Bruno Haible wrote:
> Hi,
> 
> Darshit Shah wrote:
>> I recently tried to use the hash table implementation in gnulib which
>> resides in the "hash" module. However, I quickly realised that the hash
>> table in gnulib seems to be what is otherwise popularly known as a hash
>> set, i.e., it supports storing and retrieving just values from the
>> structure.
>> 
>> On the other hand, a hash table is usually expected to have a key->value 
>> mapping that is stored.
> 
> I agree that the gnulib 'hash' module is just a particular case, and 
> probably the module name is not very descriptive.
> 
>> Within GNU Wget, we have a fairly portable version of a hash table
>> implemented which I think would be a good addition for gnulib. What do you
>> think?
> 
> There's not only the one from wget but also the one from gettext and the one
> from glib https://gitlab.gnome.org/GNOME/glib/blob/master/glib/ghash.h 
> https://gitlab.gnome.org/GNOME/glib/blob/master/glib/ghash.c
> 
> and the one from libxml and the ones from CLN and many more.
> 

There was a hashtable shootout[1] recently, with a followup[2] (although that
one is glib-specific):

[1]: https://hpjansson.org/blag/2018/07/24/a-hash-table-re-hash/
[2]: https://hpjansson.org/blag/2018/08/29/what-ails-ghashtable/



signature.asc
Description: OpenPGP digital signature

Re: test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.04.2013 00:00, Eric Blake wrote:
 On 04/01/2013 04:48 PM, Eric Blake wrote:
 On 04/01/2013 04:36 PM, LRN wrote:
 Apparently, the MSVCRT implementation  of fseek() is used.
 
 If not, then we should fix the m4 tests to filter out
 the buggy W32 fseek and install the gnulib replacement.
 
 I'm unsure of how they work.
 
 What does 'grep _FSEEK config.status' show?
 $ grep _FSEEK config.status S[REPLACE_FSEEKO]=0 
 S[REPLACE_FSEEK]=0
 
 Well, apparently the m4 files don't think they need to replace
 fseek...
 
 S[HAVE_FSEEKO]=1 S[HAVE_DECL_FSEEKO]=1 
 S[GNULIB_FSEEKO]=1 S[GNULIB_FSEEK]=1
 
 ...even though the gnulib modules are in use...
 
 D[HAVE_FSEEKO]= 1 D[HAVE_DECL_FSEEKO]= 1 
 D[GNULIB_TEST_FSEEK]= 1 D[GNULIB_TEST_FSEEKO]= 1 
 D[HAVE_RAW_DECL_FSEEKO]= 1
 
 How about 'grep LSEEK_PIPE config.h'?
 $ grep LSEEK_PIPE config.status D[LSEEK_PIPE_BROKEN]= 1
 
 ...and even though we know seek is broken on the platform.  Looks
 like I'll have to figure out what went wrong; I'll probably have
 a patch in the next 24 hours or so.
 
 I'm still stumped on how to reproduce this; on latest gnulib.git 
 installed in a Cygwin setup, I did:
 
 ./gnulib-tool --create-testdir --dir=testdir0 fseeko
 
 then in that directory did a configure with a cross compiler:
 
 ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
 
 and the resulting build passed all tests.  Looking in
 config.status, I see:
 
 S[REPLACE_FSEEKO]=0 S[REPLACE_FSEEK]=1 
 S[HAVE_FSEEKO]=0 S[HAVE_DECL_FSEEKO]=0
 
 which differs from your setup.  Maybe I should repeat my tests
 with mingw64 instead of the older mingw32?
 
H-m-m-m...if the problem is in the way gnulib detects whether it needs
to replace fseek or not, then using mingw-w64 might give you different
results, since mingw.org and mingw-w64 headers and crt differ
significantly.
I'll try doing the same thing you listed above on my msys+mingw-w64
installation. Any particular things in the output i should send back?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRXI8qAAoJEOs4Jb6SI2CwwXQH/imkrd7aEvYz7YE7QYTDas93
20ky7qmAe2rq7Eeqg1FLtwS08qhF3K+F0w8aLunOm9Xcx5GTkORR/F6Wv//ClHne
0lZ6HwJw3OZzwkPxdiRxsOXyjhB8WI5uGmxsXZaIHsEYGIs0GmA7EpqHZmv6389J
WlppHea07XU7y2pnqg2ZzFr7/DhFp0poUafnNt5QBUP3mM1RhodgHbmjp9/jQhvq
7gYJUdSrK7SyZwKHhL1+q/GQy87c33K4vMjMOqyIAMiwNAf9iQidlV5mtmZl/s6Q
fLHn7D2Rb5t8Sw5cd84XxhL17gmLiBvtQ+7t6eEDTnYigYLcDbtAXANpKtnR3WU=
=y+rT
-END PGP SIGNATURE-

Re: test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.04.2013 00:21, LRN wrote:
 On 04.04.2013 00:00, Eric Blake wrote:
 On 04/01/2013 04:48 PM, Eric Blake wrote:
 On 04/01/2013 04:36 PM, LRN wrote:
 Apparently, the MSVCRT implementation  of fseek() is
 used.
 
 If not, then we should fix the m4 tests to filter out 
 the buggy W32 fseek and install the gnulib
 replacement.
 
 I'm unsure of how they work.
 
 What does 'grep _FSEEK config.status' show?
 $ grep _FSEEK config.status S[REPLACE_FSEEKO]=0 
 S[REPLACE_FSEEK]=0
 
 Well, apparently the m4 files don't think they need to replace 
 fseek...
 
 S[HAVE_FSEEKO]=1 S[HAVE_DECL_FSEEKO]=1 
 S[GNULIB_FSEEKO]=1 S[GNULIB_FSEEK]=1
 
 ...even though the gnulib modules are in use...
 
 D[HAVE_FSEEKO]= 1 D[HAVE_DECL_FSEEKO]= 1 
 D[GNULIB_TEST_FSEEK]= 1 D[GNULIB_TEST_FSEEKO]= 1 
 D[HAVE_RAW_DECL_FSEEKO]= 1
 
 How about 'grep LSEEK_PIPE config.h'?
 $ grep LSEEK_PIPE config.status D[LSEEK_PIPE_BROKEN]= 1
 
 ...and even though we know seek is broken on the platform.
 Looks like I'll have to figure out what went wrong; I'll
 probably have a patch in the next 24 hours or so.
 
 I'm still stumped on how to reproduce this; on latest gnulib.git
  installed in a Cygwin setup, I did:
 
 ./gnulib-tool --create-testdir --dir=testdir0 fseeko
 
 then in that directory did a configure with a cross compiler:
 
 ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
 
 and the resulting build passed all tests.  Looking in 
 config.status, I see:
 
 S[REPLACE_FSEEKO]=0 S[REPLACE_FSEEK]=1 
 S[HAVE_FSEEKO]=0 S[HAVE_DECL_FSEEKO]=0
 
 which differs from your setup.  Maybe I should repeat my tests 
 with mingw64 instead of the older mingw32?
 
 H-m-m-m...if the problem is in the way gnulib detects whether it
 needs to replace fseek or not, then using mingw-w64 might give you
 different results, since mingw.org and mingw-w64 headers and crt
 differ significantly. I'll try doing the same thing you listed
 above on my msys+mingw-w64 installation. Any particular things in
 the output i should send back?
 
 
$ ./gnulib-tool --create-testdir --dir=testdir0 fseeko

$ cd testdir0

$ ./configure --prefix=/mingw --build=i686-w64-mingw32
- --host=i686-w64-mingw32

$ grep _FSEEK config.status
S[REPLACE_FSEEKO]=0
S[REPLACE_FSEEK]=0
S[HAVE_FSEEKO]=1
S[HAVE_DECL_FSEEKO]=1
S[GNULIB_FSEEKO]=1
S[GNULIB_FSEEK]=1
D[HAVE_FSEEKO]= 1
D[HAVE_DECL_FSEEKO]= 1
D[GNULIB_TEST_FSEEK]= 1
D[GNULIB_TEST_FSEEKO]= 1
D[HAVE_RAW_DECL_FSEEKO]= 1

$ make check
...
FAIL: test-fseek.sh
...
FAIL: test-fseeko.sh
...

I'm using mingw-w64 svn r5685 and i686-w64-mingw32-gcc-4.8.0

Hacked up configure script to spew out some data.
Turns out,
WINDOWS_64_BIT_OFF_T=0, but gl_cv_var_stdin_large_offset=yes
mingw-w64 supports LFO, and gnulib doesn't think that it's appropriate
to override it.

I've looked at gl_STDIN_LARGE_OFFSET, and i'm not quite sure if it
tests anything other than cygwin.
So WINDOWS_64_BIT_OFF_T=0 is the thing that differs between mingw.org
and mingw-w64. AFAIU, mingw-w64 has 64-bit offset if
_FILE_OFFSET_BITS=64 is defined.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRXJifAAoJEOs4Jb6SI2CwA8sIAIIq7fG/K+gCSXnUOOsE2YVC
YJe4zdoSpH7Z5Pk0N9eC2A41u9Dvp1oAP5N+p1xtxY3p3XaiLfz8qqrp6jg9vF6y
8h49wJzajXHGphobHFOH7onEHg+7x0sbwfGCKsMX93QT0M9vocx78wIOVFcgSwSA
bN4AgRaRVzFPlIV5pAg9DmPDV6D9ZvhHSfMFwCeo/0JHJeEiShiR+RVixm78+iPn
GrJJ/TWl3njBmje1hBw1fkxRroPAgDSuLD/3zg2hFQec4/mqVsH2O0/c2k1Ahe2y
NNcg/2afLrm5EDCa+6bwB9L8L7qPSfEg7jfCuVo7xMwYzh9qI1UIUY1SALte+7c=
=8DCR
-END PGP SIGNATURE-

test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

it does fseek on stdin.
That is supposed to succeed when stdin is a file, and fail when stdin
is a pipe.
On W32 it always succeeds, even on a pipe, and thus fseek test fails.
Should that be fixed, or marked as XFAIL on W32?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRWgRnAAoJEOs4Jb6SI2Cw7kUIAM2uqm+zpDH+ngoma/0PMTdi
hqgwZRS/B0MDZThy4Sl4GIiyLkscB0c0BH4hJ0u6oixie1YlTQbmUuNqVY7Rovu/
l06tC9q73q5sBm3QZSt7H6pYVId3p3KPqVmoms+YIsvwfxWKkolOdXNn9mVT36xt
L5O529055TgGlM9vuwUJ8l9c2F2KJPPLSGA0bP8AV/Sw0TFmHzOYt9sZCMZY46BV
B5G+ChbHuCyXXeGY5x294lOqAjGgU6W3ZYOyGnUDmFy8ksp8DRcYlTLJeDSDvLEF
UbzNm9r4h/hcQoiYKnqUbRaF8eVe7vKgJ47x8oeaM8C2/QQbxRPohg3DzWMm8EA=
=XsML
-END PGP SIGNATURE-

Re: test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02.04.2013 02:10, Eric Blake wrote:
 On 04/01/2013 04:04 PM, LRN wrote:
 it does fseek on stdin. That is supposed to succeed when stdin is
 a file, and fail when stdin is a pipe. On W32 it always succeeds,
 even on a pipe, and thus fseek test fails. Should that be fixed,
 or marked as XFAIL on W32?
 
 That should be fixed, since a seek succeeding on a pipe is contrary
 to POSIX.  Is fseek being replaced on W32?
The package that hosts the instance of gnulib on which the failure was
observed is GnuTLS-3.1.5. I'm not sure whether it replaces fseek or
not, i don't see anything like that in its configure.ac, and there is
no special configure for its gl subdirectory. However, that
subdirectory does have fseek.c and fseeko.c, and m4 subsubdirectory
has fseek.m4. But fseeko.o or fseek.o are not produced when the
packages is compiled.

 If so, the gnulib replacement has a bug - it should be preventing
 fseek() from succeeding on a pipe.
Apparently, the MSVCRT implementation  of fseek() is used.

 If not, then we should fix the m4 tests to filter out the buggy
 W32 fseek and install the gnulib replacement.
 
I'm unsure of how they work.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRWglSAAoJEOs4Jb6SI2CweVgH/AmEjqdes8pR+za6CQuK+eKT
ydNxg/G8/x8aQEpMJACiWtY5CYHftvvFLytGVbwBUCMXytU5SERNkAV8nkRUbTXy
kKOgX3zljfcXHE27I08/6y+td9H1WZ3HyznpVoUK5id20nZbLLj1rNCcO4zzvjau
YVJF3dh2hG3Xe83xzMtX1xQO4a1nZIUL5StUJDpjFbypb8HbbOYHdCNlyQjei+rc
WU8NqEr1xHtEAsSJGAtV96VGIg+fqXFzPVHmQuAA+5FYhIWtimMzaknE2qKM/oTa
MLr47/X0fsqzyKDsGtz07rahVmdsWFsxZyhMwO10JIGDosahEWMQtM3b7mSjHRQ=
=s9Rv
-END PGP SIGNATURE-

Re: test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02.04.2013 02:34, Eric Blake wrote:
 On 04/01/2013 04:25 PM, LRN wrote:
 The package that hosts the instance of gnulib on which the
 failure was observed is GnuTLS-3.1.5.
 
 What commit of gnulib was in use by this GnuTLS release?  Is it a
 case where gnutls needs to pull in a newer version of gnulib, or is
 it already something fairly recent?
 
It's fairly recent, they seem to be updating regularly.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRWguwAAoJEOs4Jb6SI2Cw7PgIAM3DuPlrRokb59bT2ENUWYOC
bfYMlDMV3UtK3JbVgAeUsllXBwGdNcShMwlvmqU2MPH06tm1dExUDeLpgzaqG2F6
/wc4W+a0+Wrn2P+Z2GSlBJyUGrUw32ctOwhf6dgWT0/mzoWhJV2O5rdyOxmArmh5
gf8FcX4ajVz7j8H1w18fUCN1mCRkvBiQnznglWq43n3pqp3W3DMcQjeU1oy6MY+a
2lEeX/1ErLoPG/64wZGP0ldOq916CD7bklQtS5RhhqQBpZIbYl5tpsD4gIJRPY2w
moULvmpEaT3KK2tOLkWUmV3w5IwDzLi23/9f6MWCq0JoIC51IOCNIloyCJv6htM=
=oz5O
-END PGP SIGNATURE-

Re: test-fseek fails on W32

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02.04.2013 02:33, Eric Blake wrote:
 On 04/01/2013 04:25 PM, LRN wrote:
 That should be fixed, since a seek succeeding on a pipe is
 contrary to POSIX.  Is fseek being replaced on W32?
 The package that hosts the instance of gnulib on which the
 failure was observed is GnuTLS-3.1.5. I'm not sure whether it
 replaces fseek or not, i don't see anything like that in its
 configure.ac, and there is no special configure for its gl
 subdirectory. However, that subdirectory does have fseek.c and
 fseeko.c, and m4 subsubdirectory has fseek.m4. But fseeko.o or
 fseek.o are not produced when the packages is compiled.
 
 If so, the gnulib replacement has a bug - it should be
 preventing fseek() from succeeding on a pipe.
 Apparently, the MSVCRT implementation  of fseek() is used.
 
 If not, then we should fix the m4 tests to filter out the
 buggy W32 fseek and install the gnulib replacement.
 
 I'm unsure of how they work.
 
 What does 'grep _FSEEK config.status' show?
$ grep _FSEEK config.status
S[REPLACE_FSEEKO]=0
S[REPLACE_FSEEK]=0
S[HAVE_FSEEKO]=1
S[HAVE_DECL_FSEEKO]=1
S[GNULIB_FSEEKO]=1
S[GNULIB_FSEEK]=1
D[HAVE_FSEEKO]= 1
D[HAVE_DECL_FSEEKO]= 1
D[GNULIB_TEST_FSEEK]= 1
D[GNULIB_TEST_FSEEKO]= 1
D[HAVE_RAW_DECL_FSEEKO]= 1

 How about 'grep LSEEK_PIPE config.h'?
$ grep LSEEK_PIPE config.status
D[LSEEK_PIPE_BROKEN]= 1

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRWgvsAAoJEOs4Jb6SI2Cw4ZIIANhZfOpEVnq5V3nQWQj1i5aU
vR/wgwa4GKnNyYhB+fDs1aypE4/NgWi1yW/Scr3GpMTJgmVdwzXN5WEh7TUFyyXP
WZSU0X6Z/Poh36+JPESmSYm55c4PvDswVfpqAs7xmqgH8FlrjYVNMKm7TDc0q+Jd
T4fUAKxowbNiNujrbn7uh1CW17rsf7ytHf4oe3higQyLrwRwE8DWzaLTLMtAAt0r
uqqCevUrFNAWHrpo3qcA3WEOYGBsFhCVh0LaVt4dEOit2UaqrHI72WURn7+rwiHN
mqmd/eGJzEof48cfxr3R10eeYG6cmuzxM8x1BdqCxdE16LtU25JuZjRb0GdmyVk=
=P+BX
-END PGP SIGNATURE-