Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Wilfed Olaf Sulla via cygwin
>On 12/5/2019 2:16 PM, Corinna Vinschen wrote: >> On Dec 5 16:10, Ken Brown wrote: >>> On 12/5/2019 7:52 AM, Corinna Vinschen wrote: On Dec 5 10:18, Corinna Vinschen wrote: > On Dec 4 21:41, Ken Brown wrote: >> The difference is that NtCreateFile doesn't fail with >> STATUS_OBJE

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Norton Allen
On 12/5/2019 2:44 PM, Ken Brown wrote: Then I wonder what's different about Wilfed's setup that causes an attempt to open Z: when it's offline. I'm grasping at straws, but could the difference be related to the fact that his drive Z: is not a Samba share? Here's an excerpt from the mount output

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Ken Brown
On 12/5/2019 2:16 PM, Corinna Vinschen wrote: > On Dec 5 16:10, Ken Brown wrote: >> On 12/5/2019 7:52 AM, Corinna Vinschen wrote: >>> On Dec 5 10:18, Corinna Vinschen wrote: On Dec 4 21:41, Ken Brown wrote: > The difference is that NtCreateFile doesn't fail with > STATUS_OBJECT_NAME

Re: [gcc libm][coshl, acoshl, cacoshf, cacosh wrong results]

2019-12-05 Thread Corinna Vinschen
Hi Daniel, On Dec 5 19:24, Daniel Kochmański wrote: > Hey, > > while testing ECL on Cygwin I've encountered a few issues with how the > functions coshl and acoshl treat infinities (long double > functions). Results are invalid and that does not happen on Linux. Most of the long double functions

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Corinna Vinschen
On Dec 5 16:10, Ken Brown wrote: > On 12/5/2019 7:52 AM, Corinna Vinschen wrote: > > On Dec 5 10:18, Corinna Vinschen wrote: > >> On Dec 4 21:41, Ken Brown wrote: > >>> The difference is that NtCreateFile doesn't fail with > >>> STATUS_OBJECT_NAME_NOT_FOUND in the other cases, so the code contai

[gcc libm][coshl, acoshl, cacoshf, cacosh wrong results]

2019-12-05 Thread Daniel Kochmański
Hey, while testing ECL on Cygwin I've encountered a few issues with how the functions coshl and acoshl treat infinities (long double functions). Results are invalid and that does not happen on Linux. Please consider the following code: -- cut -- #include #include #include int main () { lon

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Ken Brown
On 12/5/2019 7:52 AM, Corinna Vinschen wrote: > On Dec 5 10:18, Corinna Vinschen wrote: >> On Dec 4 21:41, Ken Brown wrote: >>> The difference is that NtCreateFile doesn't fail with >>> STATUS_OBJECT_NAME_NOT_FOUND in the other cases, so the code containing the >>> assertion doesn't get run. >>>

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Corinna Vinschen
On Dec 5 10:18, Corinna Vinschen wrote: > On Dec 4 21:41, Ken Brown wrote: > > The difference is that NtCreateFile doesn't fail with > > STATUS_OBJECT_NAME_NOT_FOUND in the other cases, so the code containing the > > assertion doesn't get run. > > > > BTW, I just tried the following on my syst

3.0.7: Possible sshd bug when running as a service and public key offered

2019-12-05 Thread Christopher Mapes
I sent a two-part emails about this, but somehow only the second one went through.  Apologies; The second part doesn't make much sense by itself. Following are both parts merged into one along with some edits for clarification. ~ I've found an interesting issue with sshd when running as a ser

Re: 3.0.7(0.338/5/3): Possible reference to Developer's instances of dev files in deployed build

2019-12-05 Thread Corinna Vinschen
On Dec 4 21:41, Ken Brown wrote: > On 12/4/2019 4:02 PM, Wilfed Olaf Sulla via cygwin wrote: > >> On 12/4/2019 2:26 PM, Wilfed Olaf Sulla via cygwin wrote: > >>> 692 83364 [main] ls 15015 normalize_posix_path: src Z:\ > >>> 35 83399 [main] ls 15015 normalize_win32_path: Z:\ = > >>> n