Re: [EXTERNAL] dig and host don't work in IPv6

[Lee via Cygwin]

On 7/29/23, Andrew Schulman via Cygwin  wrote:
>> Sorry...  Did you try using the -d option to see what DNS servers these
>> commands try to actually connect to (and time out, eventually).
>
> No help unfortunately.
>
> $ host -d6 cygwin.com
> Trying "cygwin.com"
> ;; connection timed out; no servers could be reached

Have you tried the windows version of bind from isc.org?

I don't remember when ISC dropped (will drop?) support for windows,
but I've been using dig from the bind9.16.41 package for a while.  Not
that I use it all that much, but it works for me.. or at  least dig
does.  named on windows has something funky going on that I never
figured out, so I'm running named on Debian.

Get it here
https://ftp.isc.org/isc/bind9/9.16.41/BIND9.16.41.x64.zip

unzip and put that directory in your path
$ which dig
/cygdrive/c/Temp/BIND/dig

and have fun!
$ dig @2600:x:x:x::x:x www.google.com  +short
2607:f8b0:4004:c09::67
2607:f8b0:4004:c09::69
2607:f8b0:4004:c09::93
2607:f8b0:4004:c09::63

Lee@i3668 ~
$ dig @2600:x:x:x::x:x www.google.com a +short
172.253.122.147
172.253.122.103
172.253.122.99
172.253.122.104
172.253.122.105
172.253.122.106

ipv6 address hidden to protect the guilty :)

... hrmmm ... I just tried your "host -d6 cygwin.com" and got
$ host -d6 cygwin.com
Trying "cygwin.com"
;; connection timed out; no servers could be reached

Do you have a firewall blocking outbound udp/tcp to port 53?  I do,
which is most probably why I get the timeout.  But this works:
$ host cygwin.com 2600:x:x:x::x:x
Using domain server:
Name: 2600:x:x:202::x:x
Address: 2600:x:x:202::x:x#53
Aliases:

cygwin.com has address 8.43.85.97
cygwin.com mail is handled by 10 sourceware.org.


Maybe try using whatever dig you already have installed and do
  ipconfig /all | grep "DNS Server"
and then
  dig @ cygwin.com

Regards,
Lee


>
>> (strace can help as well, I think.)
>
> Posted at https://pastebin.com/XWwxJ41b. I'm not able to make much sense of
> it,
> except that on line 1339, I waited almost 5 seconds for sendmsg:
>
> 4964291 6958349 [isc-worker] host 20999 cygwin_sendmsg: 28 =
> sendmsg(20,
> 0x7FFDFC830, 0x0)
>
> Thanks for taking a look. I'm looking at other options in resolv.conf, but
> haven't found anything useful.
>
> I can't find any documention of the osquery option. This answer[1] says
> "res_init() uses the Windows resolver if either /etc/resolv.conf does not
> exist,
> or /etc/resolv.conf contains options osquery." Doesn't help in this case
> though.
>
> Andrew
>
> [1]
> https://stackoverflow.com/questions/10523828/how-does-gcc-cygwin-get-the-dns-server
>
>
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Bruno Haible via Cygwin]

Brian Inglis wrote:
> It seems to me that most application developers needing to support 
> non-Western-European languages might want a non-POSIX interpretation of 
> digits.

Sure. GNU libunistring has dedicated API for this:
  - 
https://www.gnu.org/software/libunistring/manual/html_node/Object-oriented-API.html
UC_DECIMAL_DIGIT_NUMBER.
  - 
https://www.gnu.org/software/libunistring/manual/html_node/Decimal-digit-value.html
  - https://www.gnu.org/software/libunistring/manual/html_node/Digit-value.html
  - 
https://www.gnu.org/software/libunistring/manual/html_node/Properties-as-objects.html
UC_PROPERTY_DECIMAL_DIGIT
  - 
https://www.gnu.org/software/libunistring/manual/html_node/Properties-as-functions.html
uc_is_property_decimal_digit

I'm sure ICU4C has similar APIs too.

> Are the Unicode character attribute classes supported for those application 
> use 
> cases that need more than POSIX limitations allow?

POSIX allows the libc to define additional character classes. But these will be
platform and locale dependent, and I don't know of any application which makes
use of such additional character classes via wctype() and iswctype().

> I know that I sometimes want to see some alternative numeric digit forms and 
> expect to be able to find those with an appropriate grep expression.

I think you can do so with GNU 'grep', when it was built with PCRE support.
PCRE includes support for Unicode character classes.


Bruno




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Brian Inglis via Cygwin]

On 2023-07-31 12:43, Bruno Haible via Cygwin wrote:

Corinna Vinschen wrote:

there are more of those expressions which are disabled on glibc and
fail on Cygwin, for instance in test-c32iscntrl.c.  Maybe it's actually
the better idea to disable them on Cygwin, too, rather than to change
a working system...


Sure. There is no standard how to map the Unicode properties to POSIX
character classes. Other than the mentioned ISO C constraints for
'digit' and 'xdigit' and a few POSIX constraints, you are free to
map them as you like. For glibc and gnulib, I mapped them in a way
that seemed to make most sense for applications. But different
people might come to different meanings of "make sense".


It seems to me that most application developers needing to support 
non-Western-European languages might want a non-POSIX interpretation of digits.


Are the Unicode character attribute classes supported for those application use 
cases that need more than POSIX limitations allow?


I know that I sometimes want to see some alternative numeric digit forms and 
expect to be able to find those with an appropriate grep expression.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Corinna Vinschen via Cygwin]

Hi Bruno,

On Jul 31 20:43, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > there are more of those expressions which are disabled on glibc and
> > fail on Cygwin, for instance in test-c32iscntrl.c.  Maybe it's actually
> > the better idea to disable them on Cygwin, too, rather than to change
> > a working system...
> 
> Sure. There is no standard how to map the Unicode properties to POSIX
> character classes. Other than the mentioned ISO C constraints for
> 'digit' and 'xdigit' and a few POSIX constraints, you are free to
> map them as you like. For glibc and gnulib, I mapped them in a way
> that seemed to make most sense for applications. But different
> people might come to different meanings of "make sense".

Ok, so I just pushed a patchset to Cygwin git, which should make GB18030
support actually work.

Also, the C11 functions c16rtomb, c32rtomb, mbrtoc16, mbrtoc32 are now
implemented in Cygwin and a uchar.h header exists now, too.

Assuming all gnulib tests disabled for GLibc in

  test-c32isalpha.c
  test-c32iscntrl.c
  test-c32isprint.c
  test-c32isgraph.c
  test-c32ispunct.c
  test-c32islower.c

will be disabled for Cygwin as well, all gb18030 and c32 tests in gnulib
work as desired now.


Thanks for your input and help!
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: {mingw64-{i686,x86_64}-,}cfitsio-4.3.0-1

[ASSI via Cygwin]

 
This is an update to the latest upstream version.

cfitsio-4.3.0-1
mingw64-i686-cfitsio-4.3.0-1
mingw64-x86_64-cfitsio-4.3.0-1


Notes
-

The build enables BZip2, cURL and multithreading support.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: {mingw64-{i686,x86_64}-,}cfitsio-4.3.0-1

[ASSI]

 
This is an update to the latest upstream version.

cfitsio-4.3.0-1
mingw64-i686-cfitsio-4.3.0-1
mingw64-x86_64-cfitsio-4.3.0-1


Notes
-

The build enables BZip2, cURL and multithreading support.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Updated: Perl distributions

[ASSI via Cygwin]

The following Perl distributions have been updated to their latest
release version available on CPAN:

x86_64
--
 perl-Alien-CFITSIO-4.3.0.0-1
 perl-Astro-FITS-CFITSIO-1.18-1

noarch
--
 perl-Business-ISBN-Data-20230729.001-1

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: Perl distributions

[ASSI]

The following Perl distributions have been updated to their latest
release version available on CPAN:

x86_64
--
 perl-Alien-CFITSIO-4.3.0.0-1
 perl-Astro-FITS-CFITSIO-1.18-1

noarch
--
 perl-Business-ISBN-Data-20230729.001-1

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Updated: {,mingw64-{i686,x86_64}-}binutils-2.41-1

[ASSI via Cygwin]

The binutils packages for Cygwin and MingW64 cross-compilation
toolchains have been updated to the upstream feature release 2.41, with
additional patches applied for Cygwin.

 binutils-2.41-1
 mingw64-i686-binutils-2.41-1
 mingw64-x86_64-binutils-2.41-1

The GNU Binutils are a collection of binary tools.  Most of these
programs use BFD, the Binary File Descriptor library, to do low-level
manipulation. Many of them also use the opcodes library to assemble and
disassemble machine instructions.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: {,mingw64-{i686,x86_64}-}binutils-2.41-1

[ASSI]

The binutils packages for Cygwin and MingW64 cross-compilation
toolchains have been updated to the upstream feature release 2.41, with
additional patches applied for Cygwin.

 binutils-2.41-1
 mingw64-i686-binutils-2.41-1
 mingw64-x86_64-binutils-2.41-1

The GNU Binutils are a collection of binary tools.  Most of these
programs use BFD, the Binary File Descriptor library, to do low-level
manipulation. Many of them also use the opcodes library to assemble and
disassemble machine instructions.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Updated: {,mingw64-{x86_64,i686}-}libarchive-3.7.1-1

[ASSI via Cygwin]

Libarchive has been updated to version 3.7.1-1, the following
(sub-)packages:

libarchive (source)
libarchive-devel
libarchive13
bsdcat
bsdcpio
bsdtar
bsdunzip

are available in the Cygwin distribution.  The MinGW64 packages for
the cross-compilation toolchains have been updated as well:

mingw64-i686-libarchive
mingw64-x86_64-libarchive

This is a minor upstream bugfix release.

DESCRIPTION
Multi-format archive and compression library
It is a portable, efficient C library that can read and write streaming
archives in a variety of formats. It also includes implementations
of the common tar, cpio, and zcat command-line tools that use the
libarchive library.

HOMEPAGE
https://www.libarchive.org/

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: {,mingw64-{x86_64,i686}-}libarchive-3.7.1-1

[ASSI]

Libarchive has been updated to version 3.7.1-1, the following
(sub-)packages:

libarchive (source)
libarchive-devel
libarchive13
bsdcat
bsdcpio
bsdtar
bsdunzip

are available in the Cygwin distribution.  The MinGW64 packages for
the cross-compilation toolchains have been updated as well:

mingw64-i686-libarchive
mingw64-x86_64-libarchive

This is a minor upstream bugfix release.

DESCRIPTION
Multi-format archive and compression library
It is a portable, efficient C library that can read and write streaming
archives in a variety of formats. It also includes implementations
of the common tar, cpio, and zcat command-line tools that use the
libarchive library.

HOMEPAGE
https://www.libarchive.org/

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Updated: gmp-6.3.0-1

[ASSI via Cygwin]

GNU Multiple Precision Arithmetic Library
=

GMP is a free library for arbitrary precision arithmetic, operating on
signed integers, rational numbers, and floating point numbers. There is
no practical limit to the precision except the ones implied by the
available memory in the machine GMP runs on. GMP has a rich set of
functions, and the functions have a regular interface.

--8<---cut here---start->8---

GMP 6.3 is upwardly source and binary compatible with 6.2, 6.1, 6.0,
5.1, 5.0, 4.x, and 3.x, except for applications that use the
semi-documented mpn_bdivmod function.

Changes between GMP version 6.2.* and 6.3.0

BUGS FIXED

A possible overflow of type int is avoided for mpz_cmp on huge
operands.

A possible error condition when a malformed file is read with
mpz_inp_raw is now correctly handled.

FEATURES

New public function mpz_prevprime, companion of the existing
mpz_nextprime.

New documented pointer types mpz_ptr, mpz_srcptr, and similar for
other GMP types. Refer to the manual for full list and suggested
usage. These types have been present in gmp.h at least since
GMP-4.0, but previously not advertised to users.

Support for 64-bit Arm under Macos.

Support for the loongarch64 CPU family.

Support for building with LTO, link-time optimisations.

SPEEDUPS

New special code for base = 2 in mpz_powm reduces the average time
for the functions that test primality.

Speedup for the function mpz_nextprime on large operands.

Speedup for multiplications (some sizes only) thanks to new internal
functions to compute small negacyclic products.

Special assembly code for IBM z13 and later "mainframe" CPUs,
resulting in a huge speedup.

Improved assembly for several 64-bit x86 CPUs, Risc-V, 64-bit Arm.


--8<---cut here---end--->8---

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: gmp-6.3.0-1

[ASSI]

GNU Multiple Precision Arithmetic Library
=

GMP is a free library for arbitrary precision arithmetic, operating on
signed integers, rational numbers, and floating point numbers. There is
no practical limit to the precision except the ones implied by the
available memory in the machine GMP runs on. GMP has a rich set of
functions, and the functions have a regular interface.

--8<---cut here---start->8---

GMP 6.3 is upwardly source and binary compatible with 6.2, 6.1, 6.0,
5.1, 5.0, 4.x, and 3.x, except for applications that use the
semi-documented mpn_bdivmod function.

Changes between GMP version 6.2.* and 6.3.0

BUGS FIXED

A possible overflow of type int is avoided for mpz_cmp on huge
operands.

A possible error condition when a malformed file is read with
mpz_inp_raw is now correctly handled.

FEATURES

New public function mpz_prevprime, companion of the existing
mpz_nextprime.

New documented pointer types mpz_ptr, mpz_srcptr, and similar for
other GMP types. Refer to the manual for full list and suggested
usage. These types have been present in gmp.h at least since
GMP-4.0, but previously not advertised to users.

Support for 64-bit Arm under Macos.

Support for the loongarch64 CPU family.

Support for building with LTO, link-time optimisations.

SPEEDUPS

New special code for base = 2 in mpz_powm reduces the average time
for the functions that test primality.

Speedup for the function mpz_nextprime on large operands.

Speedup for multiplications (some sizes only) thanks to new internal
functions to compute small negacyclic products.

Special assembly code for IBM z13 and later "mainframe" CPUs,
resulting in a huge speedup.

Improved assembly for several 64-bit x86 CPUs, Risc-V, 64-bit Arm.


--8<---cut here---end--->8---

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: posix_spawn facility

[Corinna Vinschen via Cygwin]

Hi Eric,

On Jul 31 13:58, Eric Blake via Cygwin wrote:
> Following up on an older thread:
> 
> On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote:
> > The glibc bug points to the sample posix_spawn() implementation in
> > POSIX XRAT - but that example implementation is non-normative and
> > known buggy, so it is not safe to rely on it.
> > 
> > Clarifying the wording in XRAT to explicitly mention that the example
> > is NOT bullet-proof (and that implementations should do better) is
> > probably worthwhile; I'll tackle that bug report.
> > 
> > > 
> > > Second, the rational section in POSIX explains posix_spawn and
> > > posix_spawnp, but it does *not* actually provide an example
> > > implementation of posix_spawnp, only of posix_spawn.
> > 
> > POSIX is silent as to whether posix_spawnp() has to fall back to 'sh'
> > on ENOEXEC failure.  The p suffix is indeed similar to execvp() (which
> > DOES require a fallback to sh), but it could also just mean a
> > PATH-search, and not the PATH-search-and-sh-fallback of execvp().  As
> > we now have implementations in the wild that differ in behavior, and
> > use security as a reason for the divergence, it is worth getting that
> > clarified in POSIX.  I'll file a bug against POSIX shortly, and reply
> > again once it is up.
> > 
> > My personal preference: sh fallback on ENOEXEC is useful in execvp(),
> > but a bear to get right (see
> > https://www.austingroupbugs.net/view.php?id=1645 where POSIX has a bug
> > in requiring argv[0] to be the script's filename, which breaks busybox
> > sh and is NOT what glibc does; meanwhile, musl intentionally does NOT
> > do the sh fallback), so NOT doing it in posix_spawnp() would be
> > reasonable; but we'll have to see what the rest of the Austin Group
> > says.
> 
> ...
> 
> > 
> > Yeah, it appears that POSIX is (accidentally) silent on whether
> > posix_spawnp() has to do the sh fallback on ENOEXEC; but it seems
> > quite reasonable that posix_spawn() being more like execle() must NOT
> > do a sh fallback.
> 
> The Austin Group finally visited the topic today; result is that in
> the next version of POSIX, it will be explicit that neither
> posix_spawn() nor posix_spawnp() are allowed to attempt sh fallback
> (instead, they must fail with ENOEXEC if detected in the parent, or
> with status 127 if after creating the child).
> 
> https://austingroupbugs.net/view.php?id=1674#c6411

Ok, clear words.  Fortunately I already pushed that patch a while ago:
https://cygwin.com/cgit/newlib-cygwin/commit/?id=da40bd6eaf40


Thanks for keeping us in the loop!


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: posix_spawn facility

[Eric Blake via Cygwin]

Following up on an older thread:

On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote:
> The glibc bug points to the sample posix_spawn() implementation in
> POSIX XRAT - but that example implementation is non-normative and
> known buggy, so it is not safe to rely on it.
> 
> Clarifying the wording in XRAT to explicitly mention that the example
> is NOT bullet-proof (and that implementations should do better) is
> probably worthwhile; I'll tackle that bug report.
> 
> > 
> > Second, the rational section in POSIX explains posix_spawn and
> > posix_spawnp, but it does *not* actually provide an example
> > implementation of posix_spawnp, only of posix_spawn.
> 
> POSIX is silent as to whether posix_spawnp() has to fall back to 'sh'
> on ENOEXEC failure.  The p suffix is indeed similar to execvp() (which
> DOES require a fallback to sh), but it could also just mean a
> PATH-search, and not the PATH-search-and-sh-fallback of execvp().  As
> we now have implementations in the wild that differ in behavior, and
> use security as a reason for the divergence, it is worth getting that
> clarified in POSIX.  I'll file a bug against POSIX shortly, and reply
> again once it is up.
> 
> My personal preference: sh fallback on ENOEXEC is useful in execvp(),
> but a bear to get right (see
> https://www.austingroupbugs.net/view.php?id=1645 where POSIX has a bug
> in requiring argv[0] to be the script's filename, which breaks busybox
> sh and is NOT what glibc does; meanwhile, musl intentionally does NOT
> do the sh fallback), so NOT doing it in posix_spawnp() would be
> reasonable; but we'll have to see what the rest of the Austin Group
> says.

...

> 
> Yeah, it appears that POSIX is (accidentally) silent on whether
> posix_spawnp() has to do the sh fallback on ENOEXEC; but it seems
> quite reasonable that posix_spawn() being more like execle() must NOT
> do a sh fallback.

The Austin Group finally visited the topic today; result is that in
the next version of POSIX, it will be explicit that neither
posix_spawn() nor posix_spawnp() are allowed to attempt sh fallback
(instead, they must fail with ENOEXEC if detected in the parent, or
with status 127 if after creating the child).

https://austingroupbugs.net/view.php?id=1674#c6411

Yes, it's odd that ENOEXEC normally equates to status 126, but does
not do so for posix_spawn().  If you want to add an extention
POSIX_SPAWN flag (for use in posix_spawnattr_setflags()) to further
tweak things as an extension to the standard, that would probably be
reasonable, but without implementations already implementing and
relying on such extension flags, the Austin Group did not want to
visit that topic today.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Bruno Haible via Cygwin]

Corinna Vinschen wrote:
> there are more of those expressions which are disabled on glibc and
> fail on Cygwin, for instance in test-c32iscntrl.c.  Maybe it's actually
> the better idea to disable them on Cygwin, too, rather than to change
> a working system...

Sure. There is no standard how to map the Unicode properties to POSIX
character classes. Other than the mentioned ISO C constraints for
'digit' and 'xdigit' and a few POSIX constraints, you are free to
map them as you like. For glibc and gnulib, I mapped them in a way
that seemed to make most sense for applications. But different
people might come to different meanings of "make sense".

Bruno




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Corinna Vinschen via Cygwin]

On Jul 31 19:46, Corinna Vinschen via Cygwin wrote:
> On Jul 31 16:06, Bruno Haible via Cygwin wrote:
> > Corinna Vinschen wrote:
> > > I have a problem with the c32isalpha function.
> > > 
> > > c32isalpha fails for the character U+FF11 FULLWIDTH DIGIT ONE,
> > > because it expects the character to be an alphabetic character.
> > 
> > This is not a big problem. You can see in the test-c32isalpha.c file
> > that this test is disabled for many platforms, in particular glibc.
> 
> Which is interesting, because I actually tried that today on glibc, and
> for iswalpha (0xff11) it returns 1.  So it actually behaves as the
> testcase expects.
> 
> > There's no problem with disabling it on Cygwin as well.
> 
> I'd rather make Cygwin do the same as glibc.

Hmm, there are more of those expressions which are disabled on glibc and
fail on Cygwin, for instance in test-c32iscntrl.c.  Maybe it's actually
the better idea to disable them on Cygwin, too, rather than to change
a working system...


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Corinna Vinschen via Cygwin]

On Jul 31 16:06, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > I have a problem with the c32isalpha function.
> > 
> > c32isalpha fails for the character U+FF11 FULLWIDTH DIGIT ONE,
> > because it expects the character to be an alphabetic character.
> 
> This is not a big problem. You can see in the test-c32isalpha.c file
> that this test is disabled for many platforms, in particular glibc.

Which is interesting, because I actually tried that today on glibc, and
for iswalpha (0xff11) it returns 1.  So it actually behaves as the
testcase expects.

> There's no problem with disabling it on Cygwin as well.

I'd rather make Cygwin do the same as glibc.

> > The Cygwin unicode information is automatically generated from the
> > Unicode data file UnicodeData.txt, fresh from their homepage.  iswalpha
> > in newlib is checking for the Unicode categories, using the expression:
> > 
> > return cat == CAT_LC || cat == CAT_Lu || cat == CAT_Ll || cat == CAT_Lt
> >   || cat == CAT_Lm || cat == CAT_Lo
> >   || cat == CAT_Nl // Letter_Number
> >   ;
> > 
> > with CAT_foo being equivalent to Unicode category foo.
> > 
> > Per UnicodeData.txt, ff11 is of category Nd, so it's a digit, not an
> > alphabetic character.
> 
> This is not wrong. However, see the comments in the generator of the
> gnulib tables:
> 
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/gen-uni-tables.c;h=0dceedc06cd72f886807fd575a2c4dba99cd147a;hb=HEAD#l5789
> 
>/* Consider all the non-ASCII digits as alphabetic.
>   ISO C 99 forbids us to have them in category "digit",
>   but we want iswalnum to return true on them.  */
> 
> Likewise in the generator of the glibc tables:
> 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/unicode-gen/unicode_utils.py;h=5af03113a2f1f063769752ea426fcaf6f6ba9e95;hb=HEAD#l274
> 
> The original comment (from 2000) was:
> 
>   /* SUSV2 gives us some freedom for the "digit" category, but ISO C 99
>  takes it away:
>  7.25.2.1.5:
> The iswdigit function tests for any wide character that corresponds
> to a decimal-digit character (as defined in 5.2.1).
>  5.2.1:
> the 10 decimal digits 0 1 2 3 4 5 6 7 8 9
>*/
>   return (ch >= 0x0030 && ch <= 0x0039);
> 
> The question is: In which category do you put these non-ASCII digits?
> "print" and "graph", sure. But other than that? "punct" or "alnum"?
> "punct" seems wrong. If you, like me, decide to put them in "alnum",
> then you they need to be in "alpha" or "digit" (per POSIX
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/iswalnum.html ).
> But ISO C 23 § 7.4.1.5 + § 5.2.1 does not allow them in category "digit".

Thanks for the description.  It was clear to me that they don't belong
into the ISO C digit category, but other than that...

So, if we change the expression in iswalpha_l to something like

  return cat == CAT_LC || cat == CAT_Lu || cat == CAT_Ll || cat == CAT_Lt
  || cat == CAT_Lm || cat == CAT_Lo
  || cat == CAT_Nl // Letter_Number
  /* Also all digits not allowed to be called digits per ISO C 99 */
  || (cat == CAT_Nd && !(c >= (wint_t)'0' && c <= (wint_t)'9'));
  ;

we're good?


Thanks,
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: character class "alpha"

[Bruno Haible via Cygwin]

Corinna Vinschen wrote:
> I have a problem with the c32isalpha function.
> 
> c32isalpha fails for the character U+FF11 FULLWIDTH DIGIT ONE,
> because it expects the character to be an alphabetic character.

This is not a big problem. You can see in the test-c32isalpha.c file
that this test is disabled for many platforms, in particular glibc.
There's no problem with disabling it on Cygwin as well.

> The Cygwin unicode information is automatically generated from the
> Unicode data file UnicodeData.txt, fresh from their homepage.  iswalpha
> in newlib is checking for the Unicode categories, using the expression:
> 
> return cat == CAT_LC || cat == CAT_Lu || cat == CAT_Ll || cat == CAT_Lt
>   || cat == CAT_Lm || cat == CAT_Lo
> || cat == CAT_Nl // Letter_Number
> ;
> 
> with CAT_foo being equivalent to Unicode category foo.
> 
> Per UnicodeData.txt, ff11 is of category Nd, so it's a digit, not an
> alphabetic character.

This is not wrong. However, see the comments in the generator of the
gnulib tables:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/gen-uni-tables.c;h=0dceedc06cd72f886807fd575a2c4dba99cd147a;hb=HEAD#l5789

   /* Consider all the non-ASCII digits as alphabetic.
  ISO C 99 forbids us to have them in category "digit",
  but we want iswalnum to return true on them.  */

Likewise in the generator of the glibc tables:

https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/unicode-gen/unicode_utils.py;h=5af03113a2f1f063769752ea426fcaf6f6ba9e95;hb=HEAD#l274

The original comment (from 2000) was:

  /* SUSV2 gives us some freedom for the "digit" category, but ISO C 99
 takes it away:
 7.25.2.1.5:
The iswdigit function tests for any wide character that corresponds
to a decimal-digit character (as defined in 5.2.1).
 5.2.1:
the 10 decimal digits 0 1 2 3 4 5 6 7 8 9
   */
  return (ch >= 0x0030 && ch <= 0x0039);

The question is: In which category do you put these non-ASCII digits?
"print" and "graph", sure. But other than that? "punct" or "alnum"?
"punct" seems wrong. If you, like me, decide to put them in "alnum",
then you they need to be in "alpha" or "digit" (per POSIX
https://pubs.opengroup.org/onlinepubs/9699919799/functions/iswalnum.html ).
But ISO C 23 § 7.4.1.5 + § 5.2.1 does not allow them in category "digit".

Bruno




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: GB18030 locale

[Corinna Vinschen via Cygwin]

Hi Bruno,

On Jul 31 12:07, Corinna Vinschen via Cygwin wrote:
> On Jul 29 11:53, Bruno Haible via Cygwin wrote:
> > Corinna Vinschen wrote:
> > > However, on debugging this, I see it's totally broken.  Trying to fix
> > > this in the existing functions is futile.  We need dedicated
> > > support functions for GB18030, kind of like the FreeBSD functions,
> > > just with extra support for surrogate pairs, as with our UTF8 stuff.
> > 
> > In case it helps: Find here a test suite for the various multibyte
> > functions with GB18030 specific test cases. (Extracted from gnulib.)
> > https://haible.de/bruno/gnu/testdir-gb18030.tar.gz
> 
> Thank you, I'm already hacking and testing :)

I have a problem with the c32isalpha function.

c32isalpha fails for the character U+FF11 FULLWIDTH DIGIT ONE,
because it expects the character to be an alphabetic character.

The Cygwin unicode information is automatically generated from the
Unicode data file UnicodeData.txt, fresh from their homepage.  iswalpha
in newlib is checking for the Unicode categories, using the expression:

return cat == CAT_LC || cat == CAT_Lu || cat == CAT_Ll || cat == CAT_Lt
  || cat == CAT_Lm || cat == CAT_Lo
  || cat == CAT_Nl // Letter_Number
  ;

with CAT_foo being equivalent to Unicode category foo.

Per UnicodeData.txt, ff11 is of category Nd, so it's a digit, not an
alphabetic character.

I see that Glibc returns 1 from c32isalpha for U+FF11, but I don't see
where it takes that info and why this is correct.  Can you point me to
some info on this?


Thanks,
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] pv 1.7.24-1

[Andrew Schulman via Cygwin-announce via Cygwin]

pv 1.7.24-1 is now available in Cygwin. This is a new upstream release, with
bug fixes and minor enhancements. See the upstream changelog[1] for the full
list.

pv - Pipe Viewer - is a terminal-based tool for monitoring the progress of
data through a pipeline. It can be inserted into any normal pipeline between
two processes to give a visual indication of how quickly data is passing
through, how long it has taken, how near to completion it is, and an estimate
of how long it will be until completion. Additional support is available for
multiple instances working in tandem, to give a visual indicator of relative
throughput in a complex pipeline.

For pv fun watching your computer send zeros to the bit bucket, run

pv --stop-at-size --size 100G /dev/null

Andrew E. Schulman

[1] https://www.ivarch.com/programs/pv.shtml#news

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

pv 1.7.24-1

[Andrew Schulman via Cygwin-announce]

pv 1.7.24-1 is now available in Cygwin. This is a new upstream release, with
bug fixes and minor enhancements. See the upstream changelog[1] for the full
list.

pv - Pipe Viewer - is a terminal-based tool for monitoring the progress of
data through a pipeline. It can be inserted into any normal pipeline between
two processes to give a visual indication of how quickly data is passing
through, how long it has taken, how near to completion it is, and an estimate
of how long it will be until completion. Additional support is available for
multiple instances working in tandem, to give a visual indicator of relative
throughput in a complex pipeline.

For pv fun watching your computer send zeros to the bit bucket, run

pv --stop-at-size --size 100G /dev/null

Andrew E. Schulman

[1] https://www.ivarch.com/programs/pv.shtml#news

Re: [PATCH setup] Keyboard accelerator for keep or skip

[Christian Franke via Cygwin-apps]

Jon Turney wrote:

On 25/04/2023 18:00, Christian Franke via Cygwin-apps wrote:
Use case: Easily prevent update of multiple packages in the "Pending" 
view, in particular useful if "Test" is selected.


Sorry for the delay in looking at this.  Obviously needed.


N.P.



Please apply.


Done.

Re: GB18030 locale

[Corinna Vinschen via Cygwin]

On Jul 29 11:53, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > However, on debugging this, I see it's totally broken.  Trying to fix
> > this in the existing functions is futile.  We need dedicated
> > support functions for GB18030, kind of like the FreeBSD functions,
> > just with extra support for surrogate pairs, as with our UTF8 stuff.
> 
> In case it helps: Find here a test suite for the various multibyte
> functions with GB18030 specific test cases. (Extracted from gnulib.)
> https://haible.de/bruno/gnu/testdir-gb18030.tar.gz

Thank you, I'm already hacking and testing :)


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Probable bug

[Takashi Yano via Cygwin]

On Sun, 30 Jul 2023 20:37:35 +0900
Takashi Yano wrote:
> On Sun, 30 Jul 2023 07:29:10 -0400
> Eliot Moss wrote:
> > On 7/30/2023 5:38 AM, natan_b--- via Cygwin wrote:
> > > Hi Guys
> > > 
> > > very short.
> > > 
> > > prog.c
> > > 
> > > #include 
> > >   
> > > int main()
> > > {
> > > float a=1.283;
> > > while(1)
> > > printf( "%f", a );
> > > }
> > >   
> > > run with
> > > $ ./prog.exe >/dev/null
> > >   
> > > in windows monitor process the process increase it's memory it arrive to 
> > > many  Gb.
> > > It's not a machine problem, other PC have same problem.
> > >   
> > > Same program in wsl and MSYS2 works well!
> > 
> > This probably has to do with output buffering, and may happen even without
> > the >/dev/null since there are no line ends in the output.  It may work with
> > stdbuf -o0 (as in: stdbuf -o0 ./prog.exe >/dev/null) but may cause the 
> > program
> > to run more slowly (each character is sent to the device, when then 
> > immediately
> > discards it).  It would seem you're hoping for the internal libraries to
> > recognize the case of writing to /dev/null ...
> 
> I also suspected that, however, it was not correct.
> 
> while (1) sprintf(buf, "%f\n", a);
> 
> has the same problem. :-(

I looked into this problem, and found the cause.
This is the serious bug in the commit:

commit a4705d387f7874f9a5de3ee67861773a17691643
Author: Takashi Yano 
Date:   Wed Dec 1 06:11:32 2021 +0900

ldtoa: Import gdtoa from OpenBSD.

- This patch uses gdtoa imported from OpenBSD if newlib configure
  option "--enable-newlib-use-gdtoa=no" is NOT specified.  gdtoa
  provides more accurate output and faster conversion than legacy
  ldtoa, while it requires more heap memory.

Please let me consider how to fix that.

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple