Re: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

> On Wed, 15 Aug 2018, Masamichi Hosoda wrote:
> 
>> On Linux with glibc, both strtod ("nan")
>> and strtod ("-nan") return positive NaN.
>> 
>> So I've created the patch that behaves like glibc.
>> Both strtod ("nan") and strtod ("-nan") return positive NaN.
> 
> I would suggest that you should not consider fixed bugs in glibc (bug 
> 23007 in this case) to be appropriate to emulate in other libraries.

I've create the patch that behaves to preserve the sign bit.

The result on Cygwin 64 bit (newlib, x86_64) with the patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = -nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = -nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = -nan
```

Thank you for your suggestion.
>From 91cf4a20e0773f4a38d6d56b0867fe3725859e5e Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 22:29:34 +0900
Subject: [PATCH v2 1/2] Fix strtod ("nan") returns negative NaN

The definition of qNaN for x86_64 and i386 was wrong.
So strtod ("nan") and strtold ("nan") returned negative NaN
instead of positive NaN.

strtof ("nan") returns positive NaN so it does not have this issue.

This commit fixes definition of qNaN for x86_64 and i386.
So strtod ("nan") and strtold ("nan") return positive NaN.
---
 newlib/libc/stdlib/gd_qnan.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/newlib/libc/stdlib/gd_qnan.h b/newlib/libc/stdlib/gd_qnan.h
index b775f82..8b0726a 100644
--- a/newlib/libc/stdlib/gd_qnan.h
+++ b/newlib/libc/stdlib/gd_qnan.h
@@ -26,6 +26,20 @@
 #elif defined(__IEEE_LITTLE_ENDIAN)
 
 #if !defined(__mips)
+#if defined (__x86_64__) || defined (__i386__)
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x0
+#define d_QNAN1 0x7ff8
+#define ld_QNAN0 0x0
+#define ld_QNAN1 0xc000
+#define ld_QNAN2 0x7fff
+#define ld_QNAN3 0x0
+#define ldus_QNAN0 0x0
+#define ldus_QNAN1 0x0
+#define ldus_QNAN2 0x0
+#define ldus_QNAN3 0xc000
+#define ldus_QNAN4 0x7fff
+#else
 #define f_QNAN 0xffc0
 #define d_QNAN0 0x0
 #define d_QNAN1 0xfff8
@@ -38,6 +52,7 @@
 #define ldus_QNAN2 0x0
 #define ldus_QNAN3 0xc000
 #define ldus_QNAN4 0x
+#endif
 #elif defined(__mips_nan2008)
 #define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
-- 
2.17.0

>From 51363ce08ffc587b206f2efdd72527ffba7b4381 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Wed, 15 Aug 2018 08:39:22 +0900
Subject: [PATCH v2 2/2] Fix strtof ("-nan") returns positive NaN

strtof ("-nan") returned positive NaN instead of negative NaN.
strtod ("-nan") and strtold ("-nan") return negative NaN.

Linux glibc has been fixed
that strto{f|d|ld} ("-nan") returns negative NaN.
https://sourceware.org/bugzilla/show_bug.cgi?id=23007

This commit makes strtof preserves the negative sign bit
when parsing "-nan" like glibc.
---
 newlib/libc/stdlib/strtod.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c
index 0cfa9e6..9c5ed56 100644
--- a/newlib/libc/stdlib/strtod.c
+++ b/newlib/libc/stdlib/strtod.c
@@ -1285,7 +1285,7 @@ strtof_l (const char *__restrict s00, char **__restrict se, locale_t loc)
 {
   double val = _strtod_l (_REENT, s00, se, loc);
   if (isnan (val))
-return nanf (NULL);
+return signbit (val) ? -nanf (NULL) : nanf (NULL);
   float retval = (float) val;
 #ifndef NO_ERRNO
   if (isinf (retval) && !isinf (val))
@@ -1300,7 +1300,7 @@ strtof (const char *__restrict s00,
 {
   double val = _strtod_l (_REENT, s00, se, __get_current_locale ());
   if (isnan (val))
-return nanf (NULL);
+return signbit (val) ? -nanf (NULL) : nanf (NULL);
   float retval = (float) val;
 #ifndef NO_ERRNO
   if (isinf (retval) && !isinf (val))
-- 
2.17.0



--
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: strtod ("nan") returns negative NaN

[Steven Penny]

On Tue, 14 Aug 2018 16:44:59, Eric Blake wrote:
The remaining question is whether it should turn "-NaN" into 
-NaN; and the argument that glibc JUST fixed their bug 23007 to make 
strtod("-nan") return -NaN means that Cygwin should, indeed, preserve 
the negative sign bit when parsing "-nan".


https://sourceware.org/bugzilla/show_bug.cgi?id=23007


respectfully, no, it doesnt mean that.

correct me, but Cygwin uses NewLib, not GlibC, so I would say the
"NewLib Committee" or its analog would have the say on what should happen in
this case.

Ive made my view clear already that "NaN" should never exist with a negative.
it would be equivalent to answering the question "what does blue smell like".
it just doesnt make sense.

and doing it just so that "strtod" matches "sscanf" seems like a solution going
the wrong way - we should be fixing "sscanf" to stop emitting a negative rather
than convincing "strtod" that it needs to start doing that.


--
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: strtod ("nan") returns negative NaN

[Eric Blake]

On 08/14/2018 04:31 PM, Stephen John Smoogen wrote:


The C standard disagrees with you [ISO:IEC 9899:2011, section 5.2.4.2.2]:

"An implementation may give zero and values that are not floating-point
numbers (such as infinities and NaNs) a sign or may leave them unsigned.
Wherever such values are unsigned, any requirement in this International
Standard to retrieve the sign shall produce an unspecified sign, and any
requirement to set the sign shall be ignored."



Does it disagree? I would say it did if it said MUST.. but it says MAY
I thought usually meant "be consistent with what you think is right
for your environment but yeah whatever".


Read conversely, if the implementation lets NaN have a sign (which 
Cygwin does), then retrieving and setting the sign is defined.




  And one can read the "any requirement to set the sign shall be
ignored" as being -NaN should come back as NaN. I don't know how this
is also affected by https://en.wikipedia.org/wiki/ISO/IEC_10967 which
goes to the IEEE 754 NaN is not a number (except when it is). [

It looks from my layman point of view that Cygwin is ok with sending
whatever they want back if it is implementation defined. However the
bigger case is whether they want to be similar to how the other
environments report things. Currently Cygwin reports -NaN for positive
NaN and 'NaN' for '-NaN'.. which may be ok but doesn't match the other
environments which all report NaN. [Does that make sense?]


Cygwin is indeed buggy for turning "NaN" into -NaN; that's easy enough 
to fix. The remaining question is whether it should turn "-NaN" into 
-NaN; and the argument that glibc JUST fixed their bug 23007 to make 
strtod("-nan") return -NaN means that Cygwin should, indeed, preserve 
the negative sign bit when parsing "-nan".


https://sourceware.org/bugzilla/show_bug.cgi?id=23007

So, the desired behavior:

strtod("nan") -> NaN
strtod("-nan") -> -NaN
printf("%f", NaN) -> "NaN"
printf("%f", -NaN) -> "-NaN"

and similarly for float and long double.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.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

Re: strtod ("nan") returns negative NaN

[Stephen John Smoogen]

On Tue, 14 Aug 2018 at 17:09, Andy Moreton  wrote:
>
> On Tue 14 Aug 2018, Steven Penny wrote:
> > a number can be positive or negative. as "NaN" is by definition not a 
> > number,
> > it cannot be positive or negative, it is simply itself, something anathema 
> > to
> > a number.
>
> The C standard disagrees with you [ISO:IEC 9899:2011, section 5.2.4.2.2]:
>
> "An implementation may give zero and values that are not floating-point
> numbers (such as infinities and NaNs) a sign or may leave them unsigned.
> Wherever such values are unsigned, any requirement in this International
> Standard to retrieve the sign shall produce an unspecified sign, and any
> requirement to set the sign shall be ignored."
>

Does it disagree? I would say it did if it said MUST.. but it says MAY
I thought usually meant "be consistent with what you think is right
for your environment but yeah whatever".

 And one can read the "any requirement to set the sign shall be
ignored" as being -NaN should come back as NaN. I don't know how this
is also affected by https://en.wikipedia.org/wiki/ISO/IEC_10967 which
goes to the IEEE 754 NaN is not a number (except when it is). [

It looks from my layman point of view that Cygwin is ok with sending
whatever they want back if it is implementation defined. However the
bigger case is whether they want to be similar to how the other
environments report things. Currently Cygwin reports -NaN for positive
NaN and 'NaN' for '-NaN'.. which may be ok but doesn't match the other
environments which all report NaN. [Does that make sense?]



> AndyM
>
>
> --
> 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
>


-- 
Stephen J Smoogen.

--
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: strtod ("nan") returns negative NaN

[Andy Moreton]

On Tue 14 Aug 2018, Steven Penny wrote:
> a number can be positive or negative. as "NaN" is by definition not a number,
> it cannot be positive or negative, it is simply itself, something anathema to
> a number.

The C standard disagrees with you [ISO:IEC 9899:2011, section 5.2.4.2.2]:

"An implementation may give zero and values that are not floating-point
numbers (such as infinities and NaNs) a sign or may leave them unsigned.
Wherever such values are unsigned, any requirement in this International
Standard to retrieve the sign shall produce an unspecified sign, and any
requirement to set the sign shall be ignored."

AndyM


--
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: cygserver - /usr/sbin vs /usr/bin

[Vince Rice]

> On Aug 14, 2018, at 3:05 PM, cyg Simple wrote:
> 
> On 8/13/2018 10:41 AM, Corinna Vinschen wrote:
>> …
>> 
>> cyglsa.dll requires an install script that would have to be change as
>> well.  In contrast, you'd have to make sure your new solution still
>> works for existing installations.  What's the gain?  Does it *hurt* to
>> have the stuff in /usr/bin like everything else?
>> 
> 
> No but then why have cygserver.exe in /usr/sbin?  Either there should be
> a separation because of required administrative rights or there
> shouldn't be at all.  Having it both ways is just confusing even if the
> confusion isn't apparent to you.

And just because it's confusing to you doesn't mean it's confusing to everyone
else. I for one have never been confused.


--
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: Documentation for cygwin-console-helper.exe

[cyg Simple]

On 8/13/2018 10:45 AM, Corinna Vinschen wrote:
> On Aug 13 08:57, cyg Simple wrote:
>> On 8/13/2018 3:53 AM, Corinna Vinschen wrote:
>>> On Aug 12 19:53, cyg Simple wrote:
 The documentation for cygwin-console-helper.exe is missing, not even a
 --help function.
>>>
>>> cygwin-console-helper.exe is not for the user to use, so why add
>>> user docs?  The documentation is in the source for the interested
>>> dev:
>>>
>>> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_console.cc;hb=HEAD#l2521
>>>
>>
>> How the hell am I supposed to find that by looking at
>> cygwin-console-helper.cc?
> 
> You aren't.  

But telling me something in the source code would have probably
prevented me from asking.  I don't think --help is helpful in this case
but words in comments about the reasoning for the executable is and
should always be a requirement.  What happens when those who know move
on to something better; then those that are left behind have to struggle
to find the reasons.

> The cygwin-console-helper solution is under-the-hood stuff,
> a solution for a problem which was supposed to be not user visible.

So perhaps the fact that it is user visible is the problem.  Perhaps it
should move to somewhere like /usr/libexec.

> Because, in this case user visible means it doesn't work as desired.

Well it works, it is a library helper app that hides the console of a
windowed app.  It shouldn't be in the user application space.  As it is,
it is in the open for the user to dwell on what is this app, it does
nothing useful when I run it from the console; I might as well delete
it.  Oh no, now my mintty has a console attached to every window.

-- 
cyg Simple

--
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: cygserver - /usr/sbin vs /usr/bin

[cyg Simple]

On 8/13/2018 10:41 AM, Corinna Vinschen wrote:
> On Aug 13 08:50, cyg Simple wrote:
>> On 8/13/2018 3:49 AM, Corinna Vinschen wrote:
>>> On Aug 10 11:28, cyg Simple wrote:
 Looking at the files delivered by the cygwin upgrade I see
 /usr/sbin/cygserver.exe and /usr/bin/cygserver-config.  Shouldn't
 cygserver-config reside in /usr/sbin with cygserver.exe?

>>
>> You didn't answer this with your below answer.  The cygserver-config
>> requires administrator privilege so it would be better placed with
>> cygserver.exe in sbin, IMO.
>>
 Also in that vain shouldn't cyglsa belong in /usr/sbin?
>>>
>>> Nope.  /usr/bin is where the DLLs are, so they can be found
>>> even if PATH isn't set up.
>>>
>>
>> But cyglsa{,64}.dll is a standalone without any other binary.  It is
>> only accessed by the OS for the LSA support if the registry key exists.
>> This means the cyglsa-config can be modified to point to the sbin
>> directory instead of the bin directory.  Again administrator privilege
>> is required so better placed in sbin, IMO.
> 
> cyglsa.dll requires an install script that would have to be change as
> well.  In contrast, you'd have to make sure your new solution still
> works for existing installations.  What's the gain?  Does it *hurt* to
> have the stuff in /usr/bin like everything else?
> 

No but then why have cygserver.exe in /usr/sbin?  Either there should be
a separation because of required administrative rights or there
shouldn't be at all.  Having it both ways is just confusing even if the
confusion isn't apparent to you.

> If you want trhis questionable changes desperately, feel free to provide
> patches on the cygwin-patches ML.
> 

When I feel that the answers to my question have been thought out I
would entertain a patch to cygwin-patches.  I realize the cyglsa-config
script requires a change should cyglsa*.dll moves and an update option
would need to be provided for those who have configured it already.

-- 
cyg Simple

--
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: strtod ("nan") returns negative NaN

[Joseph Myers]

On Wed, 15 Aug 2018, Masamichi Hosoda wrote:

> On Linux with glibc, both strtod ("nan")
> and strtod ("-nan") return positive NaN.
> 
> So I've created the patch that behaves like glibc.
> Both strtod ("nan") and strtod ("-nan") return positive NaN.

I would suggest that you should not consider fixed bugs in glibc (bug 
23007 in this case) to be appropriate to emulate in other libraries.

-- 
Joseph S. Myers
jos...@codesourcery.com

--
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: strtod ("nan") returns negative NaN

[Achim Gratz]

Corinna Vinschen writes:
> With your patch, strtold looks more correct, but it still prints the
> sign of NaN:
>
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
>   nan ("") = nan
>
> Question: What's wrong with that?  Wouldn't it be more correct if
> strtod returns -NaN for "-nan" as well?

That's iffy, the treatment of sign bits for NaN is quite different from
the usual arithmetic rules.  A NaN is literally "not a number", i.e. the
computation has left the domain of representable FP numbers, so it
really doesn't have a sign.  That doesn't stop folks from using the sign
bit on its representation, but that's a different story.  The sign
properly belong to what is called the "payload", which is usally
ignored.  So converting "-nan" (or NaN multiplied by -1) really ought to
be just plain NaN.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: strtod ("nan") returns negative NaN

[Steven Penny]

On Tue, 14 Aug 2018 15:23:01, Corinna Vinschen wrote:

I just wonder why returning -NaN when the input is "-nan" isn't the
better approach.  After all:

  printf ("nan (\"\") =3D %f\n", nan (""));
  printf ("-nan (\"\") =3D %f\n", -nan (""));

=3D=3D>

  nan ("") =3D nan
  -nan ("") =3D -nan

So, shouldn't the ideal outcome be this:

  strtod ("nan", NULL) =3D nan
  strtod ("-nan", NULL) =3D -nan
  strtold ("nan", NULL) =3D nan
  strtold ("-nan", NULL) =3D -nan


a number can be positive or negative. as "NaN" is by definition not a number,
it cannot be positive or negative, it is simply itself, something anathema to
a number.

The only case where "-nan" would be acceptable is the string case, but even in
that instance it is still not negative, it is merely a string that happens to
start with "hyphen-minus" U+002D, and has no bearing on a sign, just as a string
can have no sign.


--
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: Cygwin Setup 2.893 on Windows 10 Version 1709

[Marco Atzeri]

Am 14.08.2018 um 14:26 schrieb Senden, Ruediger:

Hello

The executed command line inside a .VBE program is

Errorcode is  -1
cmd.exe /c  d2u.exe -f -q -k  SOURCEFILE.DAT  &&  rcp   SOURCEFILE.DAT   
USER-at-SERVER:DISKNAME:[DIRECTORY]TARGETFILE.DAT  &&  u2d.exe -f -q -k  SOURCEFILE.DAT  
2>1>3
Errorcode is   1
Message: Copy successful

BUT NOTHING IS COPIED.


can you run the same code from a cywin shell (eg bash),
possibly one step at time ?



When I use the older CygWin version (32 bit) on Windows 10 and  exactly the 
same program the following error message is returned:
Errorcode is  -1
cmd.exe /c …
 Message:0 [main] u2d 7076 find_fast_cwd:   WARNING: Couldn’t compute 
FAST_CWD pointer. Please report this problem to the public mailing list 
cygwin@cygwin.com.
Errorcode is   1

BUT THE FILE IS COPIED.


same computer ?
The warning is due to a old version used
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings



This program has been used for years on Windows 7, 32 and 64 bit pcs, but with 
an older 32 bit version of CygWin.
The .DAT file contains normal text (like .txt od .csv files) and is produced by 
Excel.
It is used to copy data from Windows to VMS 7.3

The path variable begins with C:\cygwin\bin; …The CYGWIN variable is 
set to NODOSFILEWARNING
In the Cygwin\bin folder are Dos2Unix, Unix2Dos, d2u, u2d executables listed,

but, of course, I’m not sure whether it is a configuration problem somewhere or 
really a bug.


--


please provide the cygcheck.out as attachement, not in the mail body,
as mentioned at

Problem reports:   http://cygwin.com/problems.html




---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: strtod ("nan") returns negative NaN

[Heavenly Avenger]

Well, that's what I get in linux and cygwin for:

#include 
#include 
#include  /* the last two printfs requires this */
int main (void) {
  printf ("strtof (\"nan\", NULL) = %f\n", strtof ("nan", NULL));
  printf ("strtof (\"-nan\", NULL) = %f\n", strtof ("-nan", NULL));
  printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
  printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
  printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
  printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
  printf ("nan (\"\") = %f\n", nan (""));
  printf ("-nan (\"\") = %f\n", -nan (""));
}

I get:

Gentoo Linux (native linux)
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
nan ("") = nan
-nan ("") = -nan

cygwin 2.10.0:
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = -nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = -nan
strtold ("-nan", NULL) = -nan
nan ("") = nan
-nan ("") = -nan

So, let's hope the patch does not transform the behavior from the nan 
from math.h.


And yes, you have a good point. Just, well, different people made those 
different parts of the code so, better cygwin follow the ""convention"", 
if we can call it, that. :)



On 8/14/2018 12:35 PM, Corinna Vinschen wrote:

printf ("nan (\"\") = %f\n", nan (""));
printf ("-nan (\"\") = %f\n", -nan (""));



--
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: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

[...]
>> > With your patch, strtold looks more correct, but it still prints the
>> > sign of NaN:
>> > 
>> >   strtod ("nan", NULL) = nan
>> >   strtod ("-nan", NULL) = nan
>> >   strtold ("nan", NULL) = nan
>> >   strtold ("-nan", NULL) = -nan
>> >   nan ("") = nan
>> > 
>> > Question: What's wrong with that?  Wouldn't it be more correct if
>> > strtod returns -NaN for "-nan" as well?
>> 
>> In my investigate,
>> strtold sets sign bit when parameter has '-' character.
>> The wrong long double NaN definition is negative NaN that is set sign bit.
>> So without my patch, both strtold ("nan") and
>> strtold ("-nan") return negative NaN.
>> 
>> On the other hand, strtod inverts the sign when parameter has '-' character.
>> The wrong double NaN definition is negative NaN.
>> So without my patch, strtod ("nan") returns negative NaN
>> and strtod ("-nan") returns positive NaN.
> 
> Your patch improves the situation, that's a sure thing and I did not
> question that.
> 
> I just wonder why returning -NaN when the input is "-nan" isn't the
> better approach.  After all:
> 
>   printf ("nan (\"\") = %f\n", nan (""));
>   printf ("-nan (\"\") = %f\n", -nan (""));
> 
> ==>
> 
>   nan ("") = nan
>   -nan ("") = -nan
> 
> So, shouldn't the ideal outcome be this:
> 
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = -nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
> 
> ?

On Linux,
strtof ("nan"), strtof ("-nan"),
strtod ("nan"), strtod ("-nan"),
strtold ("nan"), and strtold ("-nan")
all return positive NaN.

My patch is for closing to the behavior of Linux.
I don't know why Linux's strtod ("-nan") does not return negative NaN.
But, probably because both positive and negative NaN behave in the same way,
I think.

Here's sample code.
```
#include 
#include 
#include 

int main (void)
{
  double pnan = nan ("");
  double nnan = -pnan;

  printf ("positive NaN == positive NaN: ");
  if (pnan == pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("negative NaN == negative NaN: ");
  if (nnan == nnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 < positive NaN: ");
  if (0 < pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 > positive NaN: ");
  if (0 > pnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 < negative NaN: ");
  if (0 < nnan)
printf ("true\n");
  else
printf ("false\n");

  printf ("0 > negative NaN: ");
  if (0 > nnan)
printf ("true\n");
  else
printf ("false\n");
}
```

Result:
```
positive NaN == positive NaN: false
negative NaN == negative NaN: false
0 < positive NaN: false
0 > positive NaN: false
0 < negative NaN: false
0 > negative NaN: false
```

--
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: strtod ("nan") returns negative NaN

[Corinna Vinschen]

On Aug 14 12:20, Heavenly Avenger wrote:
> On 8/14/2018 10:23 AM, Corinna Vinschen wrote:
> > I just wonder why returning -NaN when the input is "-nan" isn't the
> > better approach.  After all:
> > 
> >printf ("nan (\"\") = %f\n", nan (""));
> >printf ("-nan (\"\") = %f\n", -nan (""));
> > 
> > ==>
> > 
> >nan ("") = nan
> >-nan ("") = -nan
> > 
> > So, shouldn't the ideal outcome be this:
> > 
> >strtod ("nan", NULL) = nan
> >strtod ("-nan", NULL) = -nan
> >strtold ("nan", NULL) = nan
> >strtold ("-nan", NULL) = -nan
> > 
> > ?
> > 
> > Corinna
> > 
> I'd say it is not the better/best approach as, even though it makes sense,
> all other implementations or linux distributions treat it as a plain "nan".
> So anything written for linux will potentially break on cygwin, I am not
> sure this is the idea behind cygwin, right?

My point is, even the glibc printf prints a negative NaN as "-nan",
see above.  strtod/strtold returning a different NaN value looks
inconsistent.

Well, never mind.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: strtod ("nan") returns negative NaN

[Heavenly Avenger]

Here's the result for a gentoo with the same code provided by Masamichi 
Hosoda.


Linux ethereal 4.14.32-std522-amd64 #2 SMP Sat Mar 31 20:05:28 UTC 2018 
x86_64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz GenuineIntel GNU/Linux


strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan

This further supports the reasoning to always return just 'nan'.


On 8/14/2018 12:05 PM, Masamichi Hosoda wrote:

Hi

I've found that strtod ("nan") returns negative NaN on Cygwin 64 bit.
https://cygwin.com/ml/cygwin/2018-08/msg00168.html

On Linux with glibc, both strtod ("nan")
and strtod ("-nan") return positive NaN.

So I've created the patch that behaves like glibc.
Both strtod ("nan") and strtod ("-nan") return positive NaN.

Sample code:
```
#include 
#include 

int main (void)
{
   printf ("strtof (\"nan\", NULL) = %f\n", strtof ("nan", NULL));
   printf ("strtof (\"-nan\", NULL) = %f\n", strtof ("-nan", NULL));
   printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
   printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
   printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
   printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
}
```

The result of Cygwin (newlib) without my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = -nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = -nan
strtold ("-nan", NULL) = -nan
```

The result of Linux (glibc, Ubuntu 16.04):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of FreeBSD 10.1 (BSD libc):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of Cygwin (newlib) with my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

Thanks.


--
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



--
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: strtod ("nan") returns negative NaN

[Heavenly Avenger]

On 8/14/2018 10:23 AM, Corinna Vinschen wrote:

On Aug 14 21:17, Masamichi Hosoda wrote:

On Aug 14 11:56, Corinna Vinschen wrote:

On Aug 14 13:45, Masamichi Hosoda wrote:

>From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 12:50:32 +0900
Subject: [PATCH] Fix strtod ("nan") returns qNaN

The definition of qNaN for x86_64 and x86 was wrong.
So strtod ("nan") returned sNaN instead of qNaN.

Furthermore, it was inverted the sign bit with the presence of `-` character.
So strtod ("-nan") returned qNaN.

This commit fixes definition of qNaN
and removes the sign bit inversion when evaluating "nan".
---
  newlib/libc/stdlib/gd_qnan.h | 8 
  newlib/libc/stdlib/strtod.c  | 1 +
  2 files changed, 5 insertions(+), 4 deletions(-)

[...]

With your patch, strtold looks more correct, but it still prints the
sign of NaN:

   strtod ("nan", NULL) = nan
   strtod ("-nan", NULL) = nan
   strtold ("nan", NULL) = nan
   strtold ("-nan", NULL) = -nan
   nan ("") = nan

Question: What's wrong with that?  Wouldn't it be more correct if
strtod returns -NaN for "-nan" as well?

In my investigate,
strtold sets sign bit when parameter has '-' character.
The wrong long double NaN definition is negative NaN that is set sign bit.
So without my patch, both strtold ("nan") and
strtold ("-nan") return negative NaN.

On the other hand, strtod inverts the sign when parameter has '-' character.
The wrong double NaN definition is negative NaN.
So without my patch, strtod ("nan") returns negative NaN
and strtod ("-nan") returns positive NaN.

Your patch improves the situation, that's a sure thing and I did not
question that.

I just wonder why returning -NaN when the input is "-nan" isn't the
better approach.  After all:

   printf ("nan (\"\") = %f\n", nan (""));
   printf ("-nan (\"\") = %f\n", -nan (""));

==>

   nan ("") = nan
   -nan ("") = -nan

So, shouldn't the ideal outcome be this:

   strtod ("nan", NULL) = nan
   strtod ("-nan", NULL) = -nan
   strtold ("nan", NULL) = nan
   strtold ("-nan", NULL) = -nan

?

Corinna

I'd say it is not the better/best approach as, even though it makes 
sense, all other implementations or linux distributions treat it as a 
plain "nan". So anything written for linux will potentially break on 
cygwin, I am not sure this is the idea behind cygwin, right?


Besides, it only adds complexity when checking for nans, if string 
comparison is relied upon, as an additional character may show up.


As NaN is essentially not a number, what is not a number can't be said 
as positive or negative. Then we get to a whole philosophical level. It 
can, but we can't guarantee a cow (which is not a number) can be seen 
with a "positive cow". A mood (which is not a number), can be seen as 
positive or negative. Yet it will depend on your concept of a positive 
or negative mood... so... well, better not leave the algebra sign to 
this. As 0 is equal to -0. Does -0 exist? :)


--
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

strtod ("nan") returns negative NaN

[Masamichi Hosoda]

Hi

I've found that strtod ("nan") returns negative NaN on Cygwin 64 bit.
https://cygwin.com/ml/cygwin/2018-08/msg00168.html

On Linux with glibc, both strtod ("nan")
and strtod ("-nan") return positive NaN.

So I've created the patch that behaves like glibc.
Both strtod ("nan") and strtod ("-nan") return positive NaN.

Sample code:
```
#include 
#include 

int main (void)
{
  printf ("strtof (\"nan\", NULL) = %f\n", strtof ("nan", NULL));
  printf ("strtof (\"-nan\", NULL) = %f\n", strtof ("-nan", NULL));
  printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
  printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
  printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
  printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
}
```

The result of Cygwin (newlib) without my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = -nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = -nan
strtold ("-nan", NULL) = -nan
```

The result of Linux (glibc, Ubuntu 16.04):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of FreeBSD 10.1 (BSD libc):
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

The result of Cygwin (newlib) with my patch:
```
strtof ("nan", NULL) = nan
strtof ("-nan", NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
```

Thanks.
>From 91cf4a20e0773f4a38d6d56b0867fe3725859e5e Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 22:29:34 +0900
Subject: [PATCH 1/2] Fix strtod ("nan") returns negative NaN

The definition of qNaN for x86_64 and i386 was wrong.
So strtod ("nan") and strtold ("nan") returned negative NaN
instead of positive NaN.

strtof ("nan") returns positive NaN so it does not have this issue.

This commit fixes definition of qNaN for x86_64 and i386.
So strtod ("nan") and strtold ("nan") return positive NaN.
---
 newlib/libc/stdlib/gd_qnan.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/newlib/libc/stdlib/gd_qnan.h b/newlib/libc/stdlib/gd_qnan.h
index b775f82..8b0726a 100644
--- a/newlib/libc/stdlib/gd_qnan.h
+++ b/newlib/libc/stdlib/gd_qnan.h
@@ -26,6 +26,20 @@
 #elif defined(__IEEE_LITTLE_ENDIAN)
 
 #if !defined(__mips)
+#if defined (__x86_64__) || defined (__i386__)
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x0
+#define d_QNAN1 0x7ff8
+#define ld_QNAN0 0x0
+#define ld_QNAN1 0xc000
+#define ld_QNAN2 0x7fff
+#define ld_QNAN3 0x0
+#define ldus_QNAN0 0x0
+#define ldus_QNAN1 0x0
+#define ldus_QNAN2 0x0
+#define ldus_QNAN3 0xc000
+#define ldus_QNAN4 0x7fff
+#else
 #define f_QNAN 0xffc0
 #define d_QNAN0 0x0
 #define d_QNAN1 0xfff8
@@ -38,6 +52,7 @@
 #define ldus_QNAN2 0x0
 #define ldus_QNAN3 0xc000
 #define ldus_QNAN4 0x
+#endif
 #elif defined(__mips_nan2008)
 #define f_QNAN 0x7fc0
 #define d_QNAN0 0x0
-- 
2.17.0

>From 7256702e5034b016b5114dd1a6c4c1a689a17816 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 14 Aug 2018 23:12:49 +0900
Subject: [PATCH 2/2] Fix strtod ("-nan") returns negative NaN

On Linux,
glibc's strtod ("-nan") and strtold ("-nan") return positive NaN.

But, newlib's strtod ("-nan") returns negative NaN
because it inverted the sign with the presence of `-` character.
And, newlib's srtold ("-nan") returns negative NaN
because it set the sign bit with the presence of `-` character.

newlib's strtof ("-nan") returns positive NaN same as Linux glibc's.

This commit removes strtod's NaN sign inversion
and removes strtold's NaN sign bit setting.
So strtod ("-nan") and strtold ("-nan") return positive NaN
same as Linux glibc.
---
 newlib/libc/stdlib/strtod.c  | 1 +
 newlib/libc/stdlib/strtodg.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c
index 0cfa9e6..3b9fd26 100644
--- a/newlib/libc/stdlib/strtod.c
+++ b/newlib/libc/stdlib/strtod.c
@@ -451,6 +451,7 @@ _strtod_l (struct _reent *ptr, const char *__restrict s00, char **__restrict se,
 #ifndef No_Hex_NaN
 		}
 #endif
+	sign = 0;
 	goto ret;
 	}
 			  }
diff --git a/newlib/libc/stdlib/strtodg.c b/newlib/libc/stdlib/strtodg.c
index 4ac1f8e..cc2842b 100644
--- a/newlib/libc/stdlib/strtodg.c
+++ b/newlib/libc/stdlib/strtodg.c
@@ -585,6 +585,7 @@ _strtodg_l (struct _reent *p, const char *s00, char **se, FPI *fpi, Long *exp,
 	if (*s == '(') /*)*/
 		irv = hexnan(, fpi, bits);
 #endif
+	sign = 0;
 	goto infnanexp;
 	}
 			  }
-- 
2.17.0



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  

Re: strtod ("nan") returns negative NaN

[Stephen John Smoogen]

On Tue, 14 Aug 2018 at 09:23, Corinna Vinschen
 wrote:
>
> On Aug 14 21:17, Masamichi Hosoda wrote:
> > > On Aug 14 11:56, Corinna Vinschen wrote:
> > >> On Aug 14 13:45, Masamichi Hosoda wrote:
> > >> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> > >> > From: Masamichi Hosoda 
> > >> > Date: Tue, 14 Aug 2018 12:50:32 +0900
> > >> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
> > >> >
> > >> > The definition of qNaN for x86_64 and x86 was wrong.
> > >> > So strtod ("nan") returned sNaN instead of qNaN.
> > >> >
> > >> > Furthermore, it was inverted the sign bit with the presence of `-` 
> > >> > character.
> > >> > So strtod ("-nan") returned qNaN.
> > >> >
> > >> > This commit fixes definition of qNaN
> > >> > and removes the sign bit inversion when evaluating "nan".
> > >> > ---
> > >> >  newlib/libc/stdlib/gd_qnan.h | 8 
> > >> >  newlib/libc/stdlib/strtod.c  | 1 +
> > >> >  2 files changed, 5 insertions(+), 4 deletions(-)
> > >> [...]
> > > With your patch, strtold looks more correct, but it still prints the
> > > sign of NaN:
> > >
> > >   strtod ("nan", NULL) = nan
> > >   strtod ("-nan", NULL) = nan
> > >   strtold ("nan", NULL) = nan
> > >   strtold ("-nan", NULL) = -nan
> > >   nan ("") = nan
> > >
> > > Question: What's wrong with that?  Wouldn't it be more correct if
> > > strtod returns -NaN for "-nan" as well?
> >
> > In my investigate,
> > strtold sets sign bit when parameter has '-' character.
> > The wrong long double NaN definition is negative NaN that is set sign bit.
> > So without my patch, both strtold ("nan") and
> > strtold ("-nan") return negative NaN.
> >
> > On the other hand, strtod inverts the sign when parameter has '-' character.
> > The wrong double NaN definition is negative NaN.
> > So without my patch, strtod ("nan") returns negative NaN
> > and strtod ("-nan") returns positive NaN.
>
> Your patch improves the situation, that's a sure thing and I did not
> question that.
>
> I just wonder why returning -NaN when the input is "-nan" isn't the
> better approach.  After all:
>
>   printf ("nan (\"\") = %f\n", nan (""));
>   printf ("-nan (\"\") = %f\n", -nan (""));
>
> ==>
>
>   nan ("") = nan
>   -nan ("") = -nan
>
> So, shouldn't the ideal outcome be this:
>
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = -nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
>
> ?

This is going off some old memories from dealing with this looong ago
with Linux. I think that is set in the IEEE standard where there is
only a NaN and it is neither negative or positive.. it is just NaN.
While Negative NaN is possible, it is implementation defined and most
implementations seem to now default to the if you see -nan 'something
weird has happened'. I don't have access to the emails where this came
up years ago.. so I found these which might help

https://en.wikipedia.org/wiki/IEEE_754
https://en.wikipedia.org/wiki/NaN
http://www.cplusplus.com/forum/general/73201/



-- 
Stephen J Smoogen.

--
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: strtod ("nan") returns negative NaN

[Corinna Vinschen]

On Aug 14 21:17, Masamichi Hosoda wrote:
> > On Aug 14 11:56, Corinna Vinschen wrote:
> >> On Aug 14 13:45, Masamichi Hosoda wrote:
> >> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> >> > From: Masamichi Hosoda 
> >> > Date: Tue, 14 Aug 2018 12:50:32 +0900
> >> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
> >> > 
> >> > The definition of qNaN for x86_64 and x86 was wrong.
> >> > So strtod ("nan") returned sNaN instead of qNaN.
> >> > 
> >> > Furthermore, it was inverted the sign bit with the presence of `-` 
> >> > character.
> >> > So strtod ("-nan") returned qNaN.
> >> > 
> >> > This commit fixes definition of qNaN
> >> > and removes the sign bit inversion when evaluating "nan".
> >> > ---
> >> >  newlib/libc/stdlib/gd_qnan.h | 8 
> >> >  newlib/libc/stdlib/strtod.c  | 1 +
> >> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >> [...]
> > With your patch, strtold looks more correct, but it still prints the
> > sign of NaN:
> > 
> >   strtod ("nan", NULL) = nan
> >   strtod ("-nan", NULL) = nan
> >   strtold ("nan", NULL) = nan
> >   strtold ("-nan", NULL) = -nan
> >   nan ("") = nan
> > 
> > Question: What's wrong with that?  Wouldn't it be more correct if
> > strtod returns -NaN for "-nan" as well?
> 
> In my investigate,
> strtold sets sign bit when parameter has '-' character.
> The wrong long double NaN definition is negative NaN that is set sign bit.
> So without my patch, both strtold ("nan") and
> strtold ("-nan") return negative NaN.
> 
> On the other hand, strtod inverts the sign when parameter has '-' character.
> The wrong double NaN definition is negative NaN.
> So without my patch, strtod ("nan") returns negative NaN
> and strtod ("-nan") returns positive NaN.

Your patch improves the situation, that's a sure thing and I did not
question that.

I just wonder why returning -NaN when the input is "-nan" isn't the
better approach.  After all:

  printf ("nan (\"\") = %f\n", nan (""));
  printf ("-nan (\"\") = %f\n", -nan (""));

==>

  nan ("") = nan
  -nan ("") = -nan

So, shouldn't the ideal outcome be this:

  strtod ("nan", NULL) = nan
  strtod ("-nan", NULL) = -nan
  strtold ("nan", NULL) = nan
  strtold ("-nan", NULL) = -nan

?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Cygwin Setup 2.893 on Windows 10 Version 1709

[Senden, Ruediger]

Hello

The executed command line inside a .VBE program is

Errorcode is  -1
cmd.exe /c  d2u.exe -f -q -k  SOURCEFILE.DAT  &&  rcp   SOURCEFILE.DAT   
USER-at-SERVER:DISKNAME:[DIRECTORY]TARGETFILE.DAT  &&  u2d.exe -f -q -k  
SOURCEFILE.DAT  2>1>3
Errorcode is   1
Message: Copy successful

BUT NOTHING IS COPIED.


When I use the older CygWin version (32 bit) on Windows 10 and  exactly the 
same program the following error message is returned:
Errorcode is  -1
cmd.exe /c …
Message:0 [main] u2d 7076 find_fast_cwd:   WARNING: Couldn’t 
compute FAST_CWD pointer. Please report this problem to the public mailing list 
cygwin@cygwin.com.
Errorcode is   1

BUT THE FILE IS COPIED.


This program has been used for years on Windows 7, 32 and 64 bit pcs, but with 
an older 32 bit version of CygWin.
The .DAT file contains normal text (like .txt od .csv files) and is produced by 
Excel.
It is used to copy data from Windows to VMS 7.3

The path variable begins with C:\cygwin\bin; …The CYGWIN variable is 
set to NODOSFILEWARNING
In the Cygwin\bin folder are Dos2Unix, Unix2Dos, d2u, u2d executables listed,

but, of course, I’m not sure whether it is a configuration problem somewhere or 
really a bug.


--
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: strtod ("nan") returns negative NaN

[Masamichi Hosoda]

> On Aug 14 11:56, Corinna Vinschen wrote:
>> On Aug 14 13:45, Masamichi Hosoda wrote:
>> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
>> > From: Masamichi Hosoda 
>> > Date: Tue, 14 Aug 2018 12:50:32 +0900
>> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
>> > 
>> > The definition of qNaN for x86_64 and x86 was wrong.
>> > So strtod ("nan") returned sNaN instead of qNaN.
>> > 
>> > Furthermore, it was inverted the sign bit with the presence of `-` 
>> > character.
>> > So strtod ("-nan") returned qNaN.
>> > 
>> > This commit fixes definition of qNaN
>> > and removes the sign bit inversion when evaluating "nan".
>> > ---
>> >  newlib/libc/stdlib/gd_qnan.h | 8 
>> >  newlib/libc/stdlib/strtod.c  | 1 +
>> >  2 files changed, 5 insertions(+), 4 deletions(-)
>> 
>> Can you please send this patch to the newlib AT sourceware DOT org
>> mailing list?  As soon as something in newlib gets changed, a lot of
>> other targets are affected and the guys working on those targets should
>> have a chance to chime in.

I'll improve the patch and send it.
It did not consider environments excluding x86 and x86_64.

> Looks like strtold is affected as well, just differently:
> 
>   printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
>   printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
>   printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
>   printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
>   printf ("nan (\"\") = %f\n", nan (""));
> 
> ==>
> 
>   strtod ("nan", NULL) = -nan
>   strtod ("-nan", NULL) = nan
>   strtold ("nan", NULL) = -nan
>   strtold ("-nan", NULL) = -nan
>   nan ("") = nan
> 
> so it prints always -nan.
> 
> With your patch, strtold looks more correct, but it still prints the
> sign of NaN:
> 
>   strtod ("nan", NULL) = nan
>   strtod ("-nan", NULL) = nan
>   strtold ("nan", NULL) = nan
>   strtold ("-nan", NULL) = -nan
>   nan ("") = nan
> 
> Question: What's wrong with that?  Wouldn't it be more correct if
> strtod returns -NaN for "-nan" as well?

In my investigate,
strtold sets sign bit when parameter has '-' character.
The wrong long double NaN definition is negative NaN that is set sign bit.
So without my patch, both strtold ("nan") and
strtold ("-nan") return negative NaN.

On the other hand, strtod inverts the sign when parameter has '-' character.
The wrong double NaN definition is negative NaN.
So without my patch, strtod ("nan") returns negative NaN
and strtod ("-nan") returns positive NaN.

My previous patch removes the sign inversion in strtod when NaN.
But I did not fix strtold.

Perhaps, the following patch removes the sign bit setting of strtold when NaN.

```
--- a/newlib/libc/stdlib/strtodg.c
+++ b/newlib/libc/stdlib/strtodg.c
@@ -585,6 +585,7 @@ _strtodg_l (struct _reent *p, const char *s00, char **se, 
FPI *fpi, Long *exp,
if (*s == '(') /*)*/
irv = hexnan(, fpi, bits);
 #endif
+   sign = 0;
goto infnanexp;
}
  }
```

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.11.0-0.1

[Houder]

On 2018-08-14 11:50, Corinna Vinschen wrote:

On Aug 13 23:29, Houder wrote:

On 2018-08-10 14:43, Houder wrote:

[snip]


> The modication would require changing:
>
> winsup/cygwin/fenv.cc (_feinitialise() )
> winsup/cygwin/include/fenv.h (FE_ALL_EXCEPT)

GRRR! The file encoding of fenv.h is "cp1252" because of 2 characters 
in

this
line:

 Intel® 64 and IA-32 Architectures Software Developer’s Manuals:

... part of a comment at the beginning of the file.


Don't worry about it.  I converted the file to ASCII-only and pushed 
the
change.  ASCII-only is the least common denominator and is preferred 
for

sources anyway.


... even better! Thank you.

Regards,
Henri

--
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] gambas3 3.11.4-1

[Bastian Germann]

The following packages have been uploaded to the Cygwin distribution:

* gambas3-3.11.4-1
* gambas3-ide-3.11.4-1
* gambas3-runtime-3.11.4-1
* gambas3-devel-3.11.4-1
* gambas3-gb-clipper-3.11.4-1
* gambas3-gb-db-3.11.4-1
* gambas3-gb-db-form-3.11.4-1
* gambas3-gb-desktop-3.11.4-1
* gambas3-gb-desktop-x11-3.11.4-1
* gambas3-gb-eval-highlight-3.11.4-1
* gambas3-gb-form-3.11.4-1
* gambas3-gb-form-dialog-3.11.4-1
* gambas3-gb-form-editor-3.11.4-1
* gambas3-gb-form-mdi-3.11.4-1
* gambas3-gb-form-stock-3.11.4-1
* gambas3-gb-form-terminal-3.11.4-1
* gambas3-gb-image-3.11.4-1
* gambas3-gb-markdown-3.11.4-1
* gambas3-gb-net-3.11.4-1
* gambas3-gb-net-curl-3.11.4-1
* gambas3-gb-settings-3.11.4-1
* gambas3-gb-signal-3.11.4-1
* gambas3-gb-term-3.11.4-1
* gambas3-gb-util-3.11.4-1
* gambas3-gb-args-3.11.4-1
* gambas3-gb-chart-3.11.4-1
* gambas3-gb-dbus-trayicon-3.11.4-1
* gambas3-gb-logging-3.11.4-1
* gambas3-gb-media-form-3.11.4-1
* gambas3-gb-memcached-3.11.4-1
* gambas3-gb-mysql-3.11.4-1
* gambas3-gb-map-3.11.4-1
* gambas3-gb-net-pop3-3.11.4-1
* gambas3-gb-net-smtp-3.11.4-1
* gambas3-gb-report-3.11.4-1
* gambas3-gb-report2-3.11.4-1
* gambas3-gb-scanner-3.11.4-1
* gambas3-gb-term-form-3.11.4-1
* gambas3-gb-util-web-3.11.4-1
* gambas3-gb-web-3.11.4-1
* gambas3-gb-web-feed-3.11.4-1
* gambas3-gb-web-form-3.11.4-1
* gambas3-scripter-3.11.4-1
* gambas3-gb-cairo-3.11.4-1
* gambas3-gb-complex-3.11.4-1
* gambas3-gb-compress-3.11.4-1
* gambas3-gb-compress-bzlib2-3.11.4-1
* gambas3-gb-compress-zlib-3.11.4-1
* gambas3-gb-crypt-3.11.4-1
* gambas3-gb-data-3.11.4-1
* gambas3-gb-db-mysql-3.11.4-1
* gambas3-gb-db-odbc-3.11.4-1
* gambas3-gb-db-postgresql-3.11.4-1
* gambas3-gb-db-sqlite3-3.11.4-1
* gambas3-gb-dbus-3.11.4-1
* gambas3-gb-desktop-gnome-keyring-3.11.4-1
* gambas3-gb-gmp-3.11.4-1
* gambas3-gb-gsl-3.11.4-1
* gambas3-gb-gtk-3.11.4-1
* gambas3-gb-gtk-opengl-3.11.4-1
* gambas3-gb-gtk3-3.11.4-1
* gambas3-gb-httpd-3.11.4-1
* gambas3-gb-image-effect-3.11.4-1
* gambas3-gb-image-imlib-3.11.4-1
* gambas3-gb-image-io-3.11.4-1
* gambas3-gb-jit-3.11.4-1
* gambas3-gb-libxml-3.11.4-1
* gambas3-gb-media-3.11.4-1
* gambas3-gb-mime-3.11.4-1
* gambas3-gb-ncurses-3.11.4-1
* gambas3-gb-openal-3.11.4-1
* gambas3-gb-opengl-3.11.4-1
* gambas3-gb-opengl-glsl-3.11.4-1
* gambas3-gb-opengl-glu-3.11.4-1
* gambas3-gb-opengl-sge-3.11.4-1
* gambas3-gb-openssl-3.11.4-1
* gambas3-gb-option-3.11.4-1
* gambas3-gb-pcre-3.11.4-1
* gambas3-gb-pdf-3.11.4-1
* gambas3-gb-qt4-3.11.4-1
* gambas3-gb-qt4-ext-3.11.4-1
* gambas3-gb-qt4-opengl-3.11.4-1
* gambas3-gb-qt4-webkit-3.11.4-1
* gambas3-gb-qt5-3.11.4-1
* gambas3-gb-qt5-ext-3.11.4-1
* gambas3-gb-qt5-opengl-3.11.4-1
* gambas3-gb-qt5-webkit-3.11.4-1
* gambas3-gb-sdl-3.11.4-1
* gambas3-gb-sdl-sound-3.11.4-1
* gambas3-gb-sdl2-3.11.4-1
* gambas3-gb-sdl2-audio-3.11.4-1
* gambas3-gb-vb-3.11.4-1
* gambas3-gb-xml-3.11.4-1
* gambas3-gb-xml-html-3.11.4-1
* gambas3-gb-xml-rpc-3.11.4-1
* gambas3-gb-xml-xslt-3.11.4-1

Gambas is a free development environment and a full powerful
development platform based on a Basic interpreter with object
extensions, as easy as Visual Basic.

--
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

gambas3 3.11.4-1

[Bastian Germann]

The following packages have been uploaded to the Cygwin distribution:

* gambas3-3.11.4-1
* gambas3-ide-3.11.4-1
* gambas3-runtime-3.11.4-1
* gambas3-devel-3.11.4-1
* gambas3-gb-clipper-3.11.4-1
* gambas3-gb-db-3.11.4-1
* gambas3-gb-db-form-3.11.4-1
* gambas3-gb-desktop-3.11.4-1
* gambas3-gb-desktop-x11-3.11.4-1
* gambas3-gb-eval-highlight-3.11.4-1
* gambas3-gb-form-3.11.4-1
* gambas3-gb-form-dialog-3.11.4-1
* gambas3-gb-form-editor-3.11.4-1
* gambas3-gb-form-mdi-3.11.4-1
* gambas3-gb-form-stock-3.11.4-1
* gambas3-gb-form-terminal-3.11.4-1
* gambas3-gb-image-3.11.4-1
* gambas3-gb-markdown-3.11.4-1
* gambas3-gb-net-3.11.4-1
* gambas3-gb-net-curl-3.11.4-1
* gambas3-gb-settings-3.11.4-1
* gambas3-gb-signal-3.11.4-1
* gambas3-gb-term-3.11.4-1
* gambas3-gb-util-3.11.4-1
* gambas3-gb-args-3.11.4-1
* gambas3-gb-chart-3.11.4-1
* gambas3-gb-dbus-trayicon-3.11.4-1
* gambas3-gb-logging-3.11.4-1
* gambas3-gb-media-form-3.11.4-1
* gambas3-gb-memcached-3.11.4-1
* gambas3-gb-mysql-3.11.4-1
* gambas3-gb-map-3.11.4-1
* gambas3-gb-net-pop3-3.11.4-1
* gambas3-gb-net-smtp-3.11.4-1
* gambas3-gb-report-3.11.4-1
* gambas3-gb-report2-3.11.4-1
* gambas3-gb-scanner-3.11.4-1
* gambas3-gb-term-form-3.11.4-1
* gambas3-gb-util-web-3.11.4-1
* gambas3-gb-web-3.11.4-1
* gambas3-gb-web-feed-3.11.4-1
* gambas3-gb-web-form-3.11.4-1
* gambas3-scripter-3.11.4-1
* gambas3-gb-cairo-3.11.4-1
* gambas3-gb-complex-3.11.4-1
* gambas3-gb-compress-3.11.4-1
* gambas3-gb-compress-bzlib2-3.11.4-1
* gambas3-gb-compress-zlib-3.11.4-1
* gambas3-gb-crypt-3.11.4-1
* gambas3-gb-data-3.11.4-1
* gambas3-gb-db-mysql-3.11.4-1
* gambas3-gb-db-odbc-3.11.4-1
* gambas3-gb-db-postgresql-3.11.4-1
* gambas3-gb-db-sqlite3-3.11.4-1
* gambas3-gb-dbus-3.11.4-1
* gambas3-gb-desktop-gnome-keyring-3.11.4-1
* gambas3-gb-gmp-3.11.4-1
* gambas3-gb-gsl-3.11.4-1
* gambas3-gb-gtk-3.11.4-1
* gambas3-gb-gtk-opengl-3.11.4-1
* gambas3-gb-gtk3-3.11.4-1
* gambas3-gb-httpd-3.11.4-1
* gambas3-gb-image-effect-3.11.4-1
* gambas3-gb-image-imlib-3.11.4-1
* gambas3-gb-image-io-3.11.4-1
* gambas3-gb-jit-3.11.4-1
* gambas3-gb-libxml-3.11.4-1
* gambas3-gb-media-3.11.4-1
* gambas3-gb-mime-3.11.4-1
* gambas3-gb-ncurses-3.11.4-1
* gambas3-gb-openal-3.11.4-1
* gambas3-gb-opengl-3.11.4-1
* gambas3-gb-opengl-glsl-3.11.4-1
* gambas3-gb-opengl-glu-3.11.4-1
* gambas3-gb-opengl-sge-3.11.4-1
* gambas3-gb-openssl-3.11.4-1
* gambas3-gb-option-3.11.4-1
* gambas3-gb-pcre-3.11.4-1
* gambas3-gb-pdf-3.11.4-1
* gambas3-gb-qt4-3.11.4-1
* gambas3-gb-qt4-ext-3.11.4-1
* gambas3-gb-qt4-opengl-3.11.4-1
* gambas3-gb-qt4-webkit-3.11.4-1
* gambas3-gb-qt5-3.11.4-1
* gambas3-gb-qt5-ext-3.11.4-1
* gambas3-gb-qt5-opengl-3.11.4-1
* gambas3-gb-qt5-webkit-3.11.4-1
* gambas3-gb-sdl-3.11.4-1
* gambas3-gb-sdl-sound-3.11.4-1
* gambas3-gb-sdl2-3.11.4-1
* gambas3-gb-sdl2-audio-3.11.4-1
* gambas3-gb-vb-3.11.4-1
* gambas3-gb-xml-3.11.4-1
* gambas3-gb-xml-html-3.11.4-1
* gambas3-gb-xml-rpc-3.11.4-1
* gambas3-gb-xml-xslt-3.11.4-1

Gambas is a free development environment and a full powerful
development platform based on a Basic interpreter with object
extensions, as easy as Visual Basic.

Re: Regarding to problem computing FAST_CWD

[Marco Atzeri]

Am 14.08.2018 um 11:47 schrieb Jiun Hui Low:

Hi there,

I was trying to unzip a zip file and came across this,

https://www.wikihow.com/Remove-the-Password-from-a-Zip-File-Without-Knowing-the-Password

which showed steps to unzip. And here I encounter with John the Ripper. But
then I faced a issue which is "0 [ain] zip2john 12636 find-fast-cwd:
WARNING: Counldn't compute FAST_CWD pointer.

I have tried to Google for solution which lead me to,

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=e5cadbfdcdd8b06932a9503b3c72511b68f03a60


better
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings


and I installed Cygwin newest version. And nothing's changed. I don't know
what to do with it. I'm still stuck again. And I don't really understand
the solution I found. How do I proceed from here? This is like one small
problem leading to bigger problem. I'm so helpless.


have you looked for multiple versions of cygwin1.dll in your PC ?
Probably "John the Ripper" has a old copy of it.



Looking forward to hear from you soon. Thanks.

Regards,
Andy

--
Problem reports:   http://cygwin.com/problems.html


Regards
Marco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: strtod ("nan") returns negative NaN

[Corinna Vinschen]

On Aug 14 11:56, Corinna Vinschen wrote:
> On Aug 14 13:45, Masamichi Hosoda wrote:
> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> > From: Masamichi Hosoda 
> > Date: Tue, 14 Aug 2018 12:50:32 +0900
> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
> > 
> > The definition of qNaN for x86_64 and x86 was wrong.
> > So strtod ("nan") returned sNaN instead of qNaN.
> > 
> > Furthermore, it was inverted the sign bit with the presence of `-` 
> > character.
> > So strtod ("-nan") returned qNaN.
> > 
> > This commit fixes definition of qNaN
> > and removes the sign bit inversion when evaluating "nan".
> > ---
> >  newlib/libc/stdlib/gd_qnan.h | 8 
> >  newlib/libc/stdlib/strtod.c  | 1 +
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> Can you please send this patch to the newlib AT sourceware DOT org
> mailing list?  As soon as something in newlib gets changed, a lot of
> other targets are affected and the guys working on those targets should
> have a chance to chime in.

Looks like strtold is affected as well, just differently:

  printf ("strtod (\"nan\", NULL) = %f\n", strtod ("nan", NULL));
  printf ("strtod (\"-nan\", NULL) = %f\n", strtod ("-nan", NULL));
  printf ("strtold (\"nan\", NULL) = %Lf\n", strtold ("nan", NULL));
  printf ("strtold (\"-nan\", NULL) = %Lf\n", strtold ("-nan", NULL));
  printf ("nan (\"\") = %f\n", nan (""));

==>

  strtod ("nan", NULL) = -nan
  strtod ("-nan", NULL) = nan
  strtold ("nan", NULL) = -nan
  strtold ("-nan", NULL) = -nan
  nan ("") = nan

so it prints always -nan.

With your patch, strtold looks more correct, but it still prints the
sign of NaN:

  strtod ("nan", NULL) = nan
  strtod ("-nan", NULL) = nan
  strtold ("nan", NULL) = nan
  strtold ("-nan", NULL) = -nan
  nan ("") = nan

Question: What's wrong with that?  Wouldn't it be more correct if
strtod returns -NaN for "-nan" as well?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[ANNOUNCEMENT] alure 1.2-3

[Bastian Germann]

The following packages have been uploaded to the Cygwin distribution:

* alure-doc-1.2-3
* alure-utils-1.2-3
* libalure-devel-1.2-3
* libalure1-1.2-3

ALURE is a utility library to help manage common tasks with OpenAL
applications. This includes device enumeration and initialization,
file loading, and streaming.

The purpose of this library is to provide pre-made functionality that
would otherwise be repetitive or difficult to (re)code for various
projects and platforms, such as loading a sound file into an OpenAL
buffer and streaming an audio file through a buffer queue. Support for
different formats is consistent across platforms, so no special checks
are needed when loading files, and all formats are handled through the
same API.

CHANGES
* use ninja build system

--
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

alure 1.2-3

[Bastian Germann]

The following packages have been uploaded to the Cygwin distribution:

* alure-doc-1.2-3
* alure-utils-1.2-3
* libalure-devel-1.2-3
* libalure1-1.2-3

ALURE is a utility library to help manage common tasks with OpenAL
applications. This includes device enumeration and initialization,
file loading, and streaming.

The purpose of this library is to provide pre-made functionality that
would otherwise be repetitive or difficult to (re)code for various
projects and platforms, such as loading a sound file into an OpenAL
buffer and streaming an audio file through a buffer queue. Support for
different formats is consistent across platforms, so no special checks
are needed when loading files, and all formats are handled through the
same API.

CHANGES
* use ninja build system

Re: strtod ("nan") returns negative NaN

[Corinna Vinschen]

On Aug 14 13:45, Masamichi Hosoda wrote:
> >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> From: Masamichi Hosoda 
> Date: Tue, 14 Aug 2018 12:50:32 +0900
> Subject: [PATCH] Fix strtod ("nan") returns qNaN
> 
> The definition of qNaN for x86_64 and x86 was wrong.
> So strtod ("nan") returned sNaN instead of qNaN.
> 
> Furthermore, it was inverted the sign bit with the presence of `-` character.
> So strtod ("-nan") returned qNaN.
> 
> This commit fixes definition of qNaN
> and removes the sign bit inversion when evaluating "nan".
> ---
>  newlib/libc/stdlib/gd_qnan.h | 8 
>  newlib/libc/stdlib/strtod.c  | 1 +
>  2 files changed, 5 insertions(+), 4 deletions(-)

Can you please send this patch to the newlib AT sourceware DOT org
mailing list?  As soon as something in newlib gets changed, a lot of
other targets are affected and the guys working on those targets should
have a chance to chime in.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.11.0-0.1

[Corinna Vinschen]

On Aug 13 23:29, Houder wrote:
> On 2018-08-10 14:43, Houder wrote:
> > On Fri, 10 Aug 2018 13:42:54, Corinna Vinschen wrote:
> > [snip]
> > 
> > > > Note: the following line must be changed in STC-FENV.c (the STC that was
> > > > attached to the bug report -- the last one above).
> > > >
> > > > from:
> > > > const int xxx =3D 0x3d; // FE_ALL_EXCEPT on Linux, i.e. the denormal-...
> > > > // exception is excluded on Linux
> > > >
> > > > to:
> > > > const int xxx =3D 0x3f; // Cygwin allows the denormal-operand exception;
> > > > // Linux (Andreas Jaeger) does not.
> > > > // This exception is not defined by the IEEE 754
> > > > // standard (Floating-Point Arithmetic)
> > > 
> > > Shall we change that?  A patch would be nice. ;)
> > 
> > That is possible ...
> > 
> > As on Linux, the denormal-operand exception will always be masked after
> > this
> > change ... (both in the default env. and in the "nomask" env.)
> > 
> > Meaning that, after this change, this exception can * no longer * be
> > enabled
> > through the API of fenv.h
> > 
> > Objections? Anyone?
> > 
> > The modication would require changing:
> > 
> > winsup/cygwin/fenv.cc (_feinitialise() )
> > winsup/cygwin/include/fenv.h (FE_ALL_EXCEPT)
> 
> GRRR! The file encoding of fenv.h is "cp1252" because of 2 characters in
> this
> line:
> 
>  Intel® 64 and IA-32 Architectures Software Developer’s Manuals:
> 
> ... part of a comment at the beginning of the file.

Don't worry about it.  I converted the file to ASCII-only and pushed the
change.  ASCII-only is the least common denominator and is preferred for
sources anyway.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] Cygwin: fenv.h: Convert to ASCII-only

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=dbd872f4ad8ad40bd47d8ee63cd64acc89682c31

commit dbd872f4ad8ad40bd47d8ee63cd64acc89682c31
Author: Corinna Vinschen 
Date:   Tue Aug 14 11:48:29 2018 +0200

Cygwin: fenv.h: Convert to ASCII-only

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/fenv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/fenv.h b/winsup/cygwin/include/fenv.h
index 95c2e31..7ec5d4d 100644
--- a/winsup/cygwin/include/fenv.h
+++ b/winsup/cygwin/include/fenv.h
@@ -24,7 +24,7 @@ extern "C" {
  C99 Language spec (draft n1256):

 
- Intel® 64 and IA-32 Architectures Software Developer’s Manuals:
+ Intel(R) 64 and IA-32 Architectures Software Developer's Manuals:
http://www.intel.com/products/processor/manuals/
 
  GNU C library manual pages:

Regarding to problem computing FAST_CWD

[Jiun Hui Low]

Hi there,

I was trying to unzip a zip file and came across this,

https://www.wikihow.com/Remove-the-Password-from-a-Zip-File-Without-Knowing-the-Password

which showed steps to unzip. And here I encounter with John the Ripper. But
then I faced a issue which is "0 [ain] zip2john 12636 find-fast-cwd:
WARNING: Counldn't compute FAST_CWD pointer.

I have tried to Google for solution which lead me to,

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=e5cadbfdcdd8b06932a9503b3c72511b68f03a60


and I installed Cygwin newest version. And nothing's changed. I don't know
what to do with it. I'm still stuck again. And I don't really understand
the solution I found. How do I proceed from here? This is like one small
problem leading to bigger problem. I'm so helpless.

Looking forward to hear from you soon. Thanks.

Regards,
Andy

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.11.0-0.1

[john doe]

On 8/14/2018 12:26 AM, Houder wrote:

On 2018-08-14 00:16, Eric Blake wrote:

On 08/13/2018 04:29 PM, Houder wrote:


The modication would require changing:

winsup/cygwin/fenv.cc (_feinitialise() )
winsup/cygwin/include/fenv.h (FE_ALL_EXCEPT)


GRRR! The file encoding of fenv.h is "cp1252" because of 2 characters 
in this

line:

  Intel® 64 and IA-32 Architectures Software Developer’s Manuals:

... part of a comment at the beginning of the file.

(the registered trademark sign (u00ae) is encoded as 0xae (cp1252), 
while it

  would be: 0xc2 0xae, in utf-8,
  the right single quotation mark (u2019) is encoded as 0x92 
(cp1252), but in

  utf-8 it would be: 0xc2 0x80 0x98)

I intend to convert the file encoding of fenv.h to utf-8. Is that a 
"No-No"

or is it allowed? (I assume GIT will notice).


In general, git doesn't care if you change a file's encoding - that's
just another content change.  In practice, you may get weird effects
when viewing that particular patch (as the patch is not well-formed in
the new multibyte locale, and looks funky when displayed in the old
locale), and emailing a patch may require care in telling git which
encoding to use for the email; but that's cosmetic, and shouldn't
matter in the long run.  Updating the code base to uniformly use UTF-8
seems reasonable to me.


... and emailing a patch may require care in telling git which encoding
to use for the email ... Huh, huh ?

Last time I used:

  - git format-patch
  - git send-mail

Am I safe here?



To better understand what has happened in the code cosmetic changes 
should be done in separate commits.


- Code changes -- Will only change the code.
- Cosmetic changes -- Will only change the cosmetic aspect of the code 
(encoding, spacing, indentation ...)


In most cases you can simply do 'git send-email' and pass the options 
for 'git format-patch' at the end of the cmd:


$ git send-email master --to=m...@example.com --reroll-count 1 --rfc


The options '--reroll-count, --rfc' are format-patch options.

--
John Doe

--
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