Killing-Process woes
I'm spawning processes in background, but have problems killing them. Here is the setup: My script (zsh) creates one or more processes in the background, and waits until they are finished. I have also set up a trap for SIGINT, with the intention that if I press Control-C, the background processes should be killed. I have verified the setup so far, that upon Control-C, the trap function is indeed invoked, and I have all the PIDs of the background processes. The problem is with the actual killing, and here is why: The background processes are actually (zsh-) scripts, which do some setup (basically setting various environment variables), and then invoke a (Cygwin-)Ruby program which does the "real work". The program is executed by something like ruby myprog.rb (Note that this Ruby program is NOT invoked in background). When my SIGINT trap is entered, I can see from ps indeed the relationship between the processes involved, for instance 1085292966224 10536 cons33672028 08:05:10 /usr/bin/ruby 929662246224 11236 cons33672028 08:05:10 /usr/bin/zsh The PID of my background process - the zsh wrapper - in this concrete case is 9296, and we can see that this is the parent of the Ruby process, 10852. The problem is that if I just kill 9296, the Ruby process keeps running, orphaned: 10852 16224 10536 cons33672028 08:05:10 /usr/bin/ruby I've found on Stackoverflow the suggestion to treat this as a process group and use negative PIDs. I tried this too, but it didn't work. Here is a similar example: 5548 102765812 2376 cons33672028 08:20:43 /usr/bin/ruby 1027658125812 10312 cons33672028 08:20:43 /usr/bin/zsh If I do a kill -- -10276 I get the error message kill: -10276: No such process This happens both with the zsh-builtin kill and with /usr/bin/kill Is there a simple way to kill the zsh process in addition to the ruby process, or do I have to analyze the output of the ps command to manually find the PID of the Ruby process and kill it? Ronald -- Ronald Fischer http://www.fusshuhn.de/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] vinagre 3.22.0-2
The following packages have been uploaded to the Cygwin distribution: * vinagre-3.22.0-2 Vinagre is a remote desktop viewer application for the GNOME desktop which uses Virtual Network Computing (VNC), and other protocols, to remotely control another computer. Vinagre can be used to control another computer and interact with its desktop. This release was rebuilt for spice-gtk 0.33. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] remmina 1.2.0-0.4.rcgit.18
The following packages have been uploaded to the Cygwin distribution: * remmina-1.2.0-0.4.rcgit.18 * remmina-devel-1.2.0-0.4.rcgit.18 Remmina is a remote desktop client written in GTK+, aiming to be useful for system administrators and travellers, who need to work with lots of remote computers in front of either large monitors or tiny netbooks. Remmina supports multiple network protocols in an integrated and consistant user interface. Currently RDP, VNC, NX, XDMCP and SSH are supported. This release was rebuilt for spice-gtk 0.33. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] spice-gtk 0.33-1, spice 0.13.3-1
The following packages have been uploaded to the Cygwin distribution: * spice-gtk-0.33-1 * spice-protocol-0.12.12-1 * libspice-client-glib2.0_8-0.33-1 * libspice-client-glib2.0-devel-0.33-1 * libspice-client-gtk3.0_5-0.33-1 * libspice-client-gtk3.0-devel-0.33-1 * libspice-controller0-0.33-1 * libspice-controller-devel-0.33-1 * libspice-server1-0.13.3-1 (x86_64 only) * libspice-server-devel-0.13.3-1 (x86_64 only) * girepository-SpiceClientGLib2.0-0.33-1 * girepository-SpiceClientGtk3.0-0.33-1 * vala-spice-0.33-1 * mingw64-i686-spice-controller-0.33-1 * mingw64-i686-spice-glib2.0-0.33-1 * mingw64-i686-spice-gtk3.0-0.33-1 * mingw64-x86_64-spice-controller-0.33-1 * mingw64-x86_64-spice-glib2.0-0.33-1 * mingw64-x86_64-spice-gtk3.0-0.33-1 The Spice project aims to provide a complete open source solution for interaction with virtualized desktop devices. The Spice project deals with both the virtualized devices and the front-end. Interaction between front-end and back-end is done using VD-Interfaces, which can be easily utilized by a third-party component. This is an update to the latest upstream releases, which drops support for GTK+ 2 and contains an ABI break in the GTK+ 3 client library. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libusb1.0 1.0.21-1
The following packages have been uploaded to the Cygwin distribution: * libusb1.0-1.0.21-1 * libusb1.0-devel-1.0.21-1 * mingw64-i686-libusb1.0-1.0.21-1 * mingw64-x86_64-libusb1.0-1.0.21-1 libusb is a library that provides generic access to USB devices. As a library, it is meant to be used by developers, to facilitate the production of applications that communicate with USB hardware. It is portable, user-mode, and supports all versions of the USB protocol. This is an update to the latest upstream release. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Updated: setup (2.880)
From: Andrey Repin > Doesn't matter what syntax I use, I'm unable to reproduce your effects. > ... > Get rid of intercepting proxies and your problem will go away as well. > It's not a matter of syntax. I'm unaware of any proxies involved. I haven't set any up. Don't even know how. Any proxies that may be involved are outside of my control. I wonder if you have a ~/.wget-hsts file that affects your results as it did mine. --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
Greetings, Nellis, Kenneth! > The folks who couldn't reproduce it were using different > command syntax than I. Doesn't matter what syntax I use, I'm unable to reproduce your effects. > I shall change to the better syntax. Get rid of intercepting proxies and your problem will go away as well. It's not a matter of syntax. -- With best regards, Andrey Repin Monday, June 19, 2017 20:37:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Updated: setup (2.880)
The folks who couldn't reproduce it were using different
command syntax than I.
Mine: wget -O setup-x86_64.exe http://cygwin.com/setup-x86_64.exe
Theirs: wget https://cygwin.com/setup-x86_64.exe
Why did I use that syntax? Because it was given in the OP,
http://cygwin.com/ml/cygwin/2012-04/msg00714.html,
and it worked at the time, so I stuck with it.
So, experimenting with this, I was able to reproduce what I
reported from the command line using my syntax, above, again
creating the gzip formatted file. Then I tried the alternate
syntax ("Theirs"), and I got the desired executable binary,
as others have found. Then the surprising part: I then
retried my syntax, and it created the correct executable
image! I saw that this exercise created file ~/.wget-hsts,
so I deleted it, reran my syntax, and again it created the
gzip format. I also noticed that it was significantly
quicker to download the .gzip format, even though the size
difference is small.
To Jon who asks:
> Do you have something in your ~/.wgetrc to add an "accept-encoding: gzip"
> header or something?
No, I don't even have this file.
Here, I show the commands and output that corroborate my assertions:
1. reproduce original results
2. reproduce others' results
3. show others' results influences my results
4. remove hidden file to restore my original results
$ time wget -O setup-x86_64.exe http://cygwin.com/setup-x86_64.exe
--2017-06-19 13:04:16-- http://cygwin.com/setup-x86_64.exe
Resolving cygwin.com... 209.132.180.131
Connecting to cygwin.com|209.132.180.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 877562 (857K) [application/octet-stream]
Saving to: ‘setup-x86_64.exe’
setup-x86_64.exe100%[===>] 856.99K --.-KB/sin 0.01s
2017-06-19 13:04:17 (78.5 MB/s) - ‘setup-x86_64.exe’ saved [877562/877562]
real0m0.306s
user0m0.000s
sys 0m0.046s
$ ls -l
total 860
-rw-r- 1 knellis Domain Users 877562 Jun 7 12:58 setup-x86_64.exe
$ file setup-x86_64.exe
setup-x86_64.exe: gzip compressed data, from Unix
$ rm setup-x86_64.exe
$ time wget https://cygwin.com/setup-x86_64.exe
--2017-06-19 13:04:51-- https://cygwin.com/setup-x86_64.exe
Resolving cygwin.com... 209.132.180.131
Connecting to cygwin.com|209.132.180.131|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 906771 (886K) [application/octet-stream]
Saving to: ‘setup-x86_64.exe’
setup-x86_64.exe100%[===>] 885.52K 1.31MB/sin 0.7s
2017-06-19 13:04:52 (1.31 MB/s) - ‘setup-x86_64.exe’ saved [906771/906771]
real0m0.992s
user0m0.031s
sys 0m0.061s
$ ls -l
total 888
-rw-r- 1 knellis Domain Users 906771 Jun 7 12:58 setup-x86_64.exe
$ file setup-x86_64.exe
setup-x86_64.exe: PE32+ executable (GUI) x86-64, for MS Windows
$ rm setup-x86_64.exe
$ time wget -O setup-x86_64.exe http://cygwin.com/setup-x86_64.exe
URL transformed to HTTPS due to an HSTS policy
--2017-06-19 13:05:27-- https://cygwin.com/setup-x86_64.exe
Resolving cygwin.com... 209.132.180.131
Connecting to cygwin.com|209.132.180.131|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 906771 (886K) [application/octet-stream]
Saving to: ‘setup-x86_64.exe’
setup-x86_64.exe100%[===>] 885.52K 1.03MB/sin 0.8s
2017-06-19 13:05:28 (1.03 MB/s) - ‘setup-x86_64.exe’ saved [906771/906771]
real0m1.171s
user0m0.015s
sys 0m0.031s
$ ls -l
total 888
-rw-r- 1 knellis Domain Users 906771 Jun 7 12:58 setup-x86_64.exe
$ file setup-x86_64.exe
setup-x86_64.exe: PE32+ executable (GUI) x86-64, for MS Windows
$ rm setup-x86_64.exe
$ rm ~/.wget-hsts
$ time wget -O setup-x86_64.exe http://cygwin.com/setup-x86_64.exe
--2017-06-19 13:06:29-- http://cygwin.com/setup-x86_64.exe
Resolving cygwin.com... 209.132.180.131
Connecting to cygwin.com|209.132.180.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 877562 (857K) [application/octet-stream]
Saving to: ‘setup-x86_64.exe’
setup-x86_64.exe100%[===>] 856.99K 3.99MB/sin 0.2s
2017-06-19 13:06:30 (3.99 MB/s) - ‘setup-x86_64.exe’ saved [877562/877562]
real0m0.399s
user0m0.000s
sys 0m0.046s
$ ls -l
total 860
-rw-r- 1 knellis Domain Users 877562 Jun 7 12:58 setup-x86_64.exe
$ file setup-x86_64.exe
setup-x86_64.exe: gzip compressed data, from Unix
$
I shall change to the better syntax.
--Ken Nellis
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
Greetings, Jon Turney! >> $ wget https://cygwin.com/setup-x86_64.exe >> --2017-06-19 17:31:56-- https://cygwin.com/setup-x86_64.exe >> Resolving cygwin.com... 209.132.180.131 >> Connecting to cygwin.com|209.132.180.131|:443... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 906771 (886K) [application/octet-stream] >> Saving to: ‘setup-x86_64.exe’ >> >> setup-x86_64.exe100%[===>] 885.52K 550KB/sin 1.6s >> >> 2017-06-19 17:31:58 (550 KB/s) - ‘setup-x86_64.exe’ saved [906771/906771] >> >> $ file setup-x86_64.exe >> setup-x86_64.exe: PE32+ executable (GUI) x86-64, for MS Windows >> >> $ xxd setup-x86_64.exe | head -1 >> : 4d5a 9000 0300 0400 MZ.. > Do you have something in your ~/.wgetrc to add an "accept-encoding: > gzip" header or something? My bet is malicious proxy server. -- With best regards, Andrey Repin Monday, June 19, 2017 20:03:34 Sorry for my terrible english...
[ANNOUNCEMENT] Updated: libaprutil1-1.6.0-1
DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: {apr1,libapr1,libapr1-devel}-1.6.2-1
CYGWIN NEWS: The library was built with TCP_NOPUSH support disabled. Cygwin defines TCP_NOPUSH, but returns "protocol not defined" when it's used. According to http://msdn.microsoft.com/en-us/library/ms738596%28v=vs.85%29.aspx this is because Windows doesn't support it. NEWS: = Please see http://www.apache.org/dist/apr/CHANGES-APR-1.6 for more details about the upstream changes DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] procps-ng 3.3.12-2
The following packages have been uploaded to the Cygwin distribution: * procps-ng-3.3.12-2 * libprocps-ng6-3.3.12-2 * libprocps-ng-devel-3.3.12-2 This package provides command line and full screen utilities for browsing procfs, a pseudo file system dynamically generated by the kernel to provide information about the status of entries in its process table (such as whether the process is running, stopped, or a zombie). It contains free, prockill, pkill, pgrep, pmap, procps, pwdx, tload, top, uptime, vmstat, w, and watch -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
On 19/06/2017 16:29, Nellis, Kenneth wrote: #!/bin/sh # From http://cygwin.com/ml/cygwin/2012-04/msg00714.html name=setup-x86_64.exe wget -O $name --quiet http://cygwin.com/$name || exit # ACL issues require some fixing up after wget chmod +x $name exit ...but Windows complained about the file format when I tried to launch it. Then "file" told me... $ file *.exe setup-x86_64.exe: gzip compressed data, from Unix $ ...so I added suffix .gz and then used (actually) WinZip to unzip it, and it created a working setup.exe. So, is this new behavior? Is it to be expected going forward? This behaviour is not expected or wanted. I can't reproduce it, either. $ wget https://cygwin.com/setup-x86_64.exe --2017-06-19 17:31:56-- https://cygwin.com/setup-x86_64.exe Resolving cygwin.com... 209.132.180.131 Connecting to cygwin.com|209.132.180.131|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 906771 (886K) [application/octet-stream] Saving to: ‘setup-x86_64.exe’ setup-x86_64.exe100%[===>] 885.52K 550KB/sin 1.6s 2017-06-19 17:31:58 (550 KB/s) - ‘setup-x86_64.exe’ saved [906771/906771] $ file setup-x86_64.exe setup-x86_64.exe: PE32+ executable (GUI) x86-64, for MS Windows $ xxd setup-x86_64.exe | head -1 : 4d5a 9000 0300 0400 MZ.. Do you have something in your ~/.wgetrc to add an "accept-encoding: gzip" header or something? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
Greetings, Nellis, Kenneth! > name=setup-x86_64.exe > wget -O $name --quiet http://cygwin.com/$name || exit Wait, WHY do you download it over HTTP? Use HTTPS. -- With best regards, Andrey Repin Monday, June 19, 2017 19:28:44 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
Greetings, Nellis, Kenneth! > wget -O $name --quiet http://cygwin.com/$name || exit Do not use wget -O name unless you have no other choice. The construction is essentially equal to wget -O - --quiet http://cygwin.com/$name > "$name" Means, it will never allow -N to work. (When -O given, -N is silently discarded.) > ...but Windows complained about the file format when I tried to launch > it. Then "file" told me... > $ file *.exe > setup-x86_64.exe: gzip compressed data, from Unix > $ > ...so I added suffix .gz and then used (actually) WinZip to unzip > it, and it created a working setup.exe. > So, is this new behavior? Is it to be expected going forward? Not confirming, my installation went smooth, I barely noticed the setup update. (Yes, I'm running it via script too.) -- With best regards, Andrey Repin Monday, June 19, 2017 19:23:55 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.880)
On 19/06/2017 17:29, Nellis, Kenneth wrote: From: cygwin-announce-owner A new version of Setup, release 2.880, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) ... Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. So, I went to download this latest setup.exe using the script that I've been using... #!/bin/sh # From http://cygwin.com/ml/cygwin/2012-04/msg00714.html name=setup-x86_64.exe wget -O $name --quiet http://cygwin.com/$name || exit # ACL issues require some fixing up after wget chmod +x $name exit ...but Windows complained about the file format when I tried to launch it. Then "file" told me... $ file *.exe setup-x86_64.exe: gzip compressed data, from Unix $ ...so I added suffix .gz and then used (actually) WinZip to unzip it, and it created a working setup.exe. So, is this new behavior? Is it to be expected going forward? --Ken Nellis Not on this side : $ wget https://www.cygwin.com/setup-x86_64.exe --2017-06-19 18:27:55-- https://www.cygwin.com/setup-x86_64.exe Resolving www.cygwin.com... 209.132.180.131 Connecting to www.cygwin.com|209.132.180.131|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 906771 (886K) [application/octet-stream] Saving to: ‘setup-x86_64.exe’ setup-x86_64.exe100%[===>] 885.52K 381KB/sin 2.3s 2017-06-19 18:27:59 (381 KB/s) - ‘setup-x86_64.exe’ saved [906771/906771] $ wget https://www.cygwin.com/setup-x86_64.exe.sig --2017-06-19 18:29:38-- https://www.cygwin.com/setup-x86_64.exe.sig Resolving www.cygwin.com... 209.132.180.131 Connecting to www.cygwin.com|209.132.180.131|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 72 [application/pgp-signature] Saving to: ‘setup-x86_64.exe.sig’ setup-x86_64.exe.si 100%[===>] 72 --.-KB/sin 0s 2017-06-19 18:29:39 (271 KB/s) - ‘setup-x86_64.exe.sig’ saved [72/72] $ file setup-x86_64.exe setup-x86_64.exe: PE32+ executable (GUI) x86-64, for MS Windows $ gpg --verify setup-x86_64.exe.sig gpg: assuming signed data in `setup-x86_64.exe' gpg: Signature made Thu, Jun 15, 2017 8:50:31 PM CEST using DSA key ID 676041BA gpg: Good signature from "Cygwin " ... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Updated: setup (2.880)
From: cygwin-announce-owner > > A new version of Setup, release 2.880, has been uploaded to > >https://cygwin.com/setup-x86.exe (32 bit version) >https://cygwin.com/setup-x86_64.exe (64 bit version) > ... > Please send bug reports, as usual, to the public mailing list cygwin AT > cygwin DOT com. So, I went to download this latest setup.exe using the script that I've been using... #!/bin/sh # From http://cygwin.com/ml/cygwin/2012-04/msg00714.html name=setup-x86_64.exe wget -O $name --quiet http://cygwin.com/$name || exit # ACL issues require some fixing up after wget chmod +x $name exit ...but Windows complained about the file format when I tried to launch it. Then "file" told me... $ file *.exe setup-x86_64.exe: gzip compressed data, from Unix $ ...so I added suffix .gz and then used (actually) WinZip to unzip it, and it created a working setup.exe. So, is this new behavior? Is it to be expected going forward? --Ken Nellis
Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]
Hello again.
I have performed a few more tests with the program below.
The lrint() family of functions I tested all appear tohave problems with
negative numbers. There seem to be an unsigned vs. signed integer problems.
I could not find cygwin/math/lrint.c on my Cygwin installation where patches
were applied by Corinna Vinschen as discussed below. This probably reflects
that I am not familiar
with processes that go on "behind the scenes".
A workaround I applied to the program was to add:
#define lrint(x) (long int)(int)lrint(x)
to the program. This seems to work, but I expect it will fail if all the long
int digits are needed.
Program:
#include /* printf */
#include/* lrint */
// define statement put in here
int main ()
{
printf ( "long int -1 = %i\n", -1 );
printf ( "type cast -1 = %li\n", (long int)-1 );
printf ( "type cast lrint(-1.0) = %li\n", (long int)(int)lrint(-1.0) );
printf ( "rint(-1.0) = %f\n", rint(-1.0) );
printf ( "int of rint(-1.4)-0.5 = %i\n", (int)(rint(-1.4) - 0.5) );
printf ( "lrint(-1.0) = %li\n", lrint(-1.0) );
printf ( "lrintf(-1.0) = %li\n", lrintf(-1.0) );
printf ( "lrintl(-1.0) = %li\n", lrintl(-1.0) );
printf ( "llrintl(-1.0) = %lli\n", llrintl(-1.0) );
printf ( "(int)lrint(-1.0) = %i\n", (int)lrint(-1.0) );
printf ( "Typecasting llrint(-1.0) = %lli\n", (long long)(int)llrint(-1.0) );
printf ( "lrint(1.0) = %li\n", lrint(1.0) );
printf ( "llrint(1.0) = %lli\n", llrint(1.0) );
printf ( "Type cast long long unsigned -1.0 = %llu\n", (unsigned long long)-1
);
return 0;
}
/*compiled by:
gcc -Wall lrint_test.c -o lrint_test.exe
Result:
long int -1 = -1
type cast -1 = -1
type cast lrint(-1.0) = -1
rint(-1.0) = -1.00
int of rint(-1.4)-0.5 = -1
lrint(-1.0) = 4294967295
lrintf(-1.0) = 4294967295
lrintl(-1.0) = 4294967295
(int)lrint(-1.0) = -1
Typecasting llrint(-1.0) = -1
lrint(1.0) = 1
llrint(1.0) = 1
Type cast long long unsigned -1.0 = 18446744073709551615
Result with #define statement above.
long int -1 = -1
type cast -1 = -1
type cast lrint(-1.0) = -1
rint(-1.0) = -1.00
int of rint(-1.4)-0.5 = -1
lrint(-1.0) = -1
lrintf(-1.0) = 4294967295
lrintl(-1.0) = 4294967295
llrintl(-1.0) = 4294967295
(int)lrint(-1.0) = -1
Typecasting llrint(-1.0) = -1
lrint(1.0) = 1
llrint(1.0) = 1
Type cast long long unsigned -1.0 = 18446744073709551615
gcc version:
gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.*/
On May 24 07:33, Eric Blake wrote:
> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
> > type cast lrint(-1.0) = 4294967295
>
> Now that's an interesting one - it may be that cygwin1.dll actually has
> buggy behavior in lrint(). In the source code, cygwin/math/lrint.c is
> dropping down to assembly; it could very well be that the assembly code
> is incorrectly truncating things at 32 bits (where it is just fine for
> 32-bit Cygwin, but wrong for 64-bit):
>
> long lrint (double x)
> {
> long retval = 0L;
> #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) ||
> defined(__i386__)
> __asm__ __volatile__ ("fistpl %0" : "=m" (retval) : "t" (x) : "st");
> #elif defined(__arm__) || defined(_ARM_)
> retval = __lrint_internal(x);
> #endif
> return retval;
> }
>
> But I'm not an assembly coding expert, so perhaps someone else will spot
> the fix faster.
I just applied a patch to fix this. Using fistpl is fine and dandy for
Mingw because sizeof(long) == 4, but on 64 bit Cygwin this function
has to use fistpll to account for sizeof(long) == 8.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
The confidentiality or integrity of this message can not be guaranteed
following transmission on the Internet. The addressee should be aware of this
before using the contents of this message.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
