Re: Cygwin strptime() is missing "%s" which strftime() has

[Brian Inglis]

On 2017-07-25 10:47, Brian Inglis wrote:
> On 2017-07-24 17:18, Kaz Kylheku wrote:
>> On 24.07.2017 15:51, Brian Inglis wrote:
>>> On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
 Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:

> rather it's a question about portability of code that
> uses %s for both functions and expects it to work unchanged in the
> Cygwin environment.

 And the answer to that question is: such code _is_not_portable_, and 
 therefore
 that expectation is wrong.

 If that code claims to be portable, then its use of %s in either of those
 functions constitutes a _bug_.

 In the old days there was a well-known fallacy known by the slogan "all the
 world's a VAX."  Nowadays it appears to have been replaced by an equally
 wide-spread, and equally incorrect belief that all the world is Linux.  
 Well,
 it's not.  Not even the whole Un*x world is Linux.
>>>
>>> Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc, RTEMS 
>>> and
>>> Cygwin newlib, and others.
>>
>> Since the utilities depend on the C library functionality for strptime and
>> strftime, even having GNU utilities won't help.
>>
>> There doesn't appear any nice way in POSIX shell scripting to have access to
>> the seconds since the Epoch.
>>
>> If you have GNU Awk, it has some time functions like mktime, which don't rely
>> on any C library extensions.
> 
> If you have GNU gawk you probably also have GNU coreutils date, which supports
> +%s for output and -d@nn for input, whether or not the system strftime
> and strptime support %s.
> 
> GNU coreutils date with shell arithmetic is adequate to support shell script
> conversions between time scales with different epochs e.g. Julian Day, 
> Modified
> Julian Day, NTP, Unix, GPS, and calculations using those values.
> 
> Awk, JS, or some other language supporting FP is required for subsecond or
> fractional day accuracy with convenient output.

Patch in latest test release provides %s support for strptime(3) used by
strptime(1).
Another strptime(3) patch was just submitted to fix %F handling.
More newlib time patches coming to fix handling years around INT_MAX and high
values of time_t.

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

--
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: winsup/cygwin/libc/strptime.cc(__strptime) strptime %F issue

[Brian Inglis]

On 2017-08-29 13:14, Corinna Vinschen wrote:
> On Aug 29 11:56, Brian Inglis wrote:
>> On 2017-08-29 01:35, Corinna Vinschen wrote:
>>> On Aug 25 11:47, Corinna Vinschen wrote:
 On Aug 24 11:11, Brian Inglis wrote:
> On 2017-08-24 03:40, Corinna Vinschen wrote:
>> On Aug 24 11:32, Corinna Vinschen wrote:
>>> On Aug 23 13:25, Brian Inglis wrote:
 Cygwin strptime(3) (also strptime(1)) fails with default width, 
 without an
 explicit width, because of the test in the following code:

 case 'F':  /* The date as "%Y-%m-%d". */
{
  LEGAL_ALT(0);
  ymd |= SET_YMD;
  char *tmp = __strptime ((const char *) bp, "%Y-%m-%d",
  tm, era_info, alt_digits,
  locale);
  if (tmp && (uint) (tmp - (char *) bp) > width)
return NULL;
  bp = (const unsigned char *) tmp;
  continue;
}

 as default width is zero so test fails and returns NULL.

 Simple patch for this as with the other cases supporting width is to 
 change the
 test to:

  if (tmp && width && (uint) (tmp - (char *) bp) > width)

 but this does not properly support [+0] flags or width in the format as
 specified by glibc (latest POSIX punts on %F) for compatibility with 
 strftime(),
 affecting only the %Y format, supplying %[+0]F, to support signed 
 and zero
 filled fixed and variable length year fields in %F format.
>> Btw., FreeBSD's _strptime only calls _strptime recursively, without any
>> checks for field width:
> As did Cygwin, which just did a goto recurse, before it was changed to 
> support
> explicit width. Your call and option to go back and ignore it, patch bug, 
> or
> forward and support flags and width based on strftime documentation.

 Well, I guess it depends on how much time you're willing to invest here.
 If you're inclined to fix this per POSIX, you're welcome, of course.
>>>
>>> [...]
>>> Would it make sense, perhaps, if you just send the quick fix
>>> so we can get 2.9.0 out?
>> Attached - got diverted during strptime testing due to time functions gmtime,
>> localtime, mktime, strftime not properly handling struct tm->tm_year == 
>> INT_MAX
>> => year == INT_MAX + 1900 so year needs to be at least long in Cygwin 64, 
>> also
>> affecting tzcalc_limits, and depending on what is required to properly handle
>> time_t in Cygwin 32.
> 
> Sounds like you're busy with time functions for a while ;)

If either long or long long will fix both Cygwin 64 and 32 time_t and struct tm,
patches should not be long coming to a bunch of newlib time functions, although
testing it all, and redoing part of mktime, will extend that.

Running make check seems to lack support on Cygwin, so are there any buildbots
for other newlib platforms to check the patches will work there, or anyone who
could run a largish STC on some platforms?

>> From 19a3c20c705a576fee0f0e71a31f0c3ac553e612 Mon Sep 17 00:00:00 2001
>> From: Brian Inglis 
>> Date: Tue, 29 Aug 2017 11:25:43 -0600
>> Subject: [PATCH] winsup/cygwin/libc/strptime.cc(__strptime) fix %F width
>>
>> ---
>>  winsup/cygwin/libc/strptime.cc | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Pushed.

Thanks. Enjoy your vacay.

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

Re: Presence of cygwin64 elements in an existing Cygwin 32 install after updating

[Eliot Moss]

On 8/29/2017 4:57 PM, Keith Christian wrote:

More program failures.  Have rebooted and allowed system to preform rebase:


$ man httping
   0 [main] man 7688 child_info_fork::abort:
C:\cygwin\bin\cygz.dll: Loaded to different address: parent(0x36)
!= child(0x3E)
man: fork failed: Resource temporarily unavailable

Why are all of these programs failing in this way?


Sometimes I have needed to rebase all programs.  To do this,
do the command: rebase-trigger full
If you're not able to run bash to run this, you can run dash
from Windows CMD and give an explicit path, e.g.,

/cygdrive/c/cygwin/bin/rebase-trigger full

would do the right thin on my installation.  But even that won't
help if you're running 32-bit and have installed too many packages.
There is only so much room in the address space for the various
possible DLLs that might be loaded.

Regards - Eliot Moss

--
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: Presence of cygwin64 elements in an existing Cygwin 32 install after updating

[Keith Christian]

More program failures.  Have rebooted and allowed system to preform rebase:


$ man httping
  0 [main] man 7688 child_info_fork::abort:
C:\cygwin\bin\cygz.dll: Loaded to different address: parent(0x36)
!= child(0x3E)
man: fork failed: Resource temporarily unavailable

Why are all of these programs failing in this way?

Keith


On Tue, Aug 29, 2017 at 11:08 AM, Keith Christian
 wrote:
> Updated to the testing version of cygwin1.dll, rebooted, still seeing
> this dig error (updating the cygwin1.dll file may have been
> superfluous.)
>
>
> /home/keith>uname -a
> CYGWIN_NT-6.1-WOW windows-machine 2.9.0(0.317/5/3)  i686 Cygwin
>
>
> /home/keith>>dig +short -x 127.0.0.1
>   0 [main] dig (7444) C:\cygwin\bin\dig.exe: *** fatal error -
> cygheap base mismatch detected - 0x612EC408/0x84C408.
> This problem is probably due to using incompatible versions of the cygwin DLL.
> Search for cygwin1.dll using the Windows Start->Find/Search facility
> and delete all but the most recent version.  The most recent version *should*
> reside in x:\cygwin\bin, where 'x' is the drive on which you have
> installed the cygwin distribution.  Rebooting is also suggested if you
> are unable to find another cygwin DLL.
> Segmentation fault
>
> Keith

--
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: winsup/cygwin/libc/strptime.cc(__strptime) strptime %F issue

[Corinna Vinschen]

On Aug 29 11:56, Brian Inglis wrote:
> On 2017-08-29 01:35, Corinna Vinschen wrote:
> > On Aug 25 11:47, Corinna Vinschen wrote:
> >> On Aug 24 11:11, Brian Inglis wrote:
> >>> On 2017-08-24 03:40, Corinna Vinschen wrote:
>  On Aug 24 11:32, Corinna Vinschen wrote:
> > On Aug 23 13:25, Brian Inglis wrote:
> >> Cygwin strptime(3) (also strptime(1)) fails with default width, 
> >> without an
> >> explicit width, because of the test in the following code:
> >>
> >> case 'F':  /* The date as "%Y-%m-%d". */
> >>{
> >>  LEGAL_ALT(0);
> >>  ymd |= SET_YMD;
> >>  char *tmp = __strptime ((const char *) bp, "%Y-%m-%d",
> >>  tm, era_info, alt_digits,
> >>  locale);
> >>  if (tmp && (uint) (tmp - (char *) bp) > width)
> >>return NULL;
> >>  bp = (const unsigned char *) tmp;
> >>  continue;
> >>}
> >>
> >> as default width is zero so test fails and returns NULL.
> >>
> >> Simple patch for this as with the other cases supporting width is to 
> >> change the
> >> test to:
> >>
> >>  if (tmp && width && (uint) (tmp - (char *) bp) > width)
> >>
> >> but this does not properly support [+0] flags or width in the format as
> >> specified by glibc (latest POSIX punts on %F) for compatibility with 
> >> strftime(),
> >> affecting only the %Y format, supplying %[+0]F, to support signed 
> >> and zero
> >> filled fixed and variable length year fields in %F format.
>  Btw., FreeBSD's _strptime only calls _strptime recursively, without any
>  checks for field width:
> >>> As did Cygwin, which just did a goto recurse, before it was changed to 
> >>> support
> >>> explicit width. Your call and option to go back and ignore it, patch bug, 
> >>> or
> >>> forward and support flags and width based on strftime documentation.
> >>
> >> Well, I guess it depends on how much time you're willing to invest here.
> >> If you're inclined to fix this per POSIX, you're welcome, of course.
> > 
> > [...]
> > Would it make sense, perhaps, if you just send the quick fix
> > so we can get 2.9.0 out?
> Attached - got diverted during strptime testing due to time functions gmtime,
> localtime, mktime, strftime not properly handling struct tm->tm_year == 
> INT_MAX
> => year == INT_MAX + 1900 so year needs to be at least long in Cygwin 64, also
> affecting tzcalc_limits, and depending on what is required to properly handle
> time_t in Cygwin 32.

Sounds like you're busy with time functions for a while ;)

> From 19a3c20c705a576fee0f0e71a31f0c3ac553e612 Mon Sep 17 00:00:00 2001
> From: Brian Inglis 
> Date: Tue, 29 Aug 2017 11:25:43 -0600
> Subject: [PATCH] winsup/cygwin/libc/strptime.cc(__strptime) fix %F width
> 
> ---
>  winsup/cygwin/libc/strptime.cc | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Pushed.


Thanks,
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: add strptime %F fix to release notes

[Corinna Vinschen]

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

commit cdbec10e7914748792371512d4485a9d868fe549
Author: Corinna Vinschen 
Date:   Tue Aug 29 21:12:21 2017 +0200

cygwin: add strptime %F fix to release notes

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.9.0 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/winsup/cygwin/release/2.9.0 b/winsup/cygwin/release/2.9.0
index 6b1f0f2..5e105fc 100644
--- a/winsup/cygwin/release/2.9.0
+++ b/winsup/cygwin/release/2.9.0
@@ -33,3 +33,6 @@ Bug Fixes
 
 - Fix a clear screen issue in Windows console when running under codepage 
65001.
   Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00430.html
+
+- Fix bug in strptime %F field width handling.
+  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q3/msg00033.html

[newlib-cygwin] winsup/cygwin/libc/strptime.cc(__strptime) fix %F width

[Corinna Vinschen]

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

commit d8e2463c75d946f30af19705ad922085185784a5
Author: Brian Inglis 
Date:   Tue Aug 29 11:25:43 2017 -0600

winsup/cygwin/libc/strptime.cc(__strptime) fix %F width

Diff:
---
 winsup/cygwin/libc/strptime.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/libc/strptime.cc b/winsup/cygwin/libc/strptime.cc
index 7c6cc20..081aca3 100644
--- a/winsup/cygwin/libc/strptime.cc
+++ b/winsup/cygwin/libc/strptime.cc
@@ -413,13 +413,15 @@ literal:
case 'F':   /* The date as "%Y-%m-%d". */
{
  LEGAL_ALT(0);
- ymd |= SET_YMD;
  char *tmp = __strptime ((const char *) bp, "%Y-%m-%d",
  tm, era_info, alt_digits,
  locale);
- if (tmp && (uint) (tmp - (char *) bp) > width)
+ /* width max chars converted, default 10, < 6 => 6 */
+ if (tmp && (char *) bp +
+   (!width ? 10 : width < 6 ? 6 : width) < tmp)
return NULL;
  bp = (const unsigned char *) tmp;
+ ymd |= SET_YMD;
  continue;
}

Re: setup-x86.exe link on cygwin.com page downloads version 2.881, not 2.882 as advertised

[Keith Christian]

Sorry for the noise.

Thanks, Marco.

Keith

--
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: setup-x86.exe link on cygwin.com page downloads version 2.881, not 2.882 as advertised

[Marco Atzeri]

On 29/08/2017 18:21, Keith Christian wrote:

I deleted the existing setup-x86.exe, verified that it was not on in
the directory.

Downloaded setup-x86.exe from the cygwin.com page, still shows version
2.881, not 2.882.

Here is an MD5SUM and a DIR listing of what I just downloaded:

Tue 08/29/2017 10:19:16.28 c:\Users\keith\Downloads>md5sum setup-x86.exe
9afd6a83bbb7dbb55805ab113e1e618e *setup-x86.exe

08/29/2017  10:17 AM   871,955 setup-x86.exe

Keith



you are misreading the page:

current cygwin dll is 2.8.2
https://sourceware.org/ml/cygwin-announce/2017-07/msg00044.html

Setup is 2.881
https://sourceware.org/ml/cygwin-announce/2017-07/msg00017.html

--
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: Presence of cygwin64 elements in an existing Cygwin 32 install after updating

[Keith Christian]

Updated to the testing version of cygwin1.dll, rebooted, still seeing
this dig error (updating the cygwin1.dll file may have been
superfluous.)


/home/keith>uname -a
CYGWIN_NT-6.1-WOW windows-machine 2.9.0(0.317/5/3)  i686 Cygwin


/home/keith>>dig +short -x 127.0.0.1
  0 [main] dig (7444) C:\cygwin\bin\dig.exe: *** fatal error -
cygheap base mismatch detected - 0x612EC408/0x84C408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
Segmentation fault

Keith

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

setup-x86.exe link on cygwin.com page downloads version 2.881, not 2.882 as advertised

[Keith Christian]

I deleted the existing setup-x86.exe, verified that it was not on in
the directory.

Downloaded setup-x86.exe from the cygwin.com page, still shows version
2.881, not 2.882.

Here is an MD5SUM and a DIR listing of what I just downloaded:

Tue 08/29/2017 10:19:16.28 c:\Users\keith\Downloads>md5sum setup-x86.exe
9afd6a83bbb7dbb55805ab113e1e618e *setup-x86.exe

08/29/2017  10:17 AM   871,955 setup-x86.exe

Keith

--
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: binutils-2.28-3 (x86/x86_64) (Test)

[Marco Atzeri]

On 13/07/2017 11:56, JonY wrote:


The following packages have been uploaded to the Cygwin distribution:

* binutils-2.28-3

This release is marked experimental. This release should solve the
performance problems and errors with 32bit nm.


Jon,
any plan to release it and latest gcc version as stable ?

Marco



--
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: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Ken Brown]

On 5/31/2017 6:50 AM, Jon Turney wrote:

... solve some problems, perhaps add some new ones, I guess.  I'm not 100%
sure this is the right approach to take, but I wrote it, so here it is.

[...]

- As implemented, selecting "Current" overrides "Keep".  This is wrong, and a
change from current behaviour, but is probably a symptom of some deeper
confusion in the picker UI I'm not sure how to address


I think the problem might be the following lines in the definition of 
SolverSolution::update:


  if (update)
queue_push2(, SOLVER_UPDATE | SOLVER_SOLVABLE_ALL, 0);

When the prerequisite checker calls SolverSolution::update, doesn't this 
cause the upgrading of old versions that we want to keep (assuming 
"Current" has been selected)?  As a quick test, I commented out those 
lines and found that setup.exe let me keep an old version of a package.


Maybe you need to add a DISABLE_UPDATE command to the solver task list 
to implement "Keep" for packages that would otherwise be updated.


(Disclaimer: I have only looked briefly at the libsolv sources, so what 
I'm saying might be complete nonsense.)


Ken

Re: Strange bug with /dev/console in mintty

[Erik Bray]

On Wed, Aug 23, 2017 at 6:08 PM, Corinna Vinschen wrote:
> On Aug 23 10:33, Corinna Vinschen wrote:
>> On Aug 22 18:49, Erik Bray wrote:
>> > Hi folks,
>> >
>> > I noticed a strange discrepancy when running Cygwin through mintty, vs
>> > through a normal cmd.exe console.  This is on a build from the latest
>> > git master, but also on Cygwin 2.8.0.  When run from a cmd.exe
>> > console, we can see the following output from fhandler_dev::readdir:
>> >
>> > $ ls -l /dev/con*
>> > crw-rw-rw- 4 Erik M. Bray Erik M. Bray 3, 0 Aug 22 18:29 /dev/conin
>> > crw-rw-rw- 4 Erik M. Bray Erik M. Bray 3, 0 Aug 22 18:29 /dev/conout
>> > crw-rw-rw- 4 Erik M. Bray Erik M. Bray 3, 0 Aug 22 18:29 /dev/cons0
>> > crw-rw-rw- 4 Erik M. Bray Erik M. Bray 3, 0 Aug 22 18:29 /dev/console
>> >
>> > The same command when run in mintty returns:
>> >
>> > crw-rw-rw- 1 Erik M. Bray Erik M. Bray 5, 255 Aug 22 18:29 /dev/conin
>> > crw-rw-rw- 1 Erik M. Bray Erik M. Bray 5, 254 Aug 22 18:29 /dev/conout
>> > crw-rw-rw- 1 Erik M. Bray Erik M. Bray 5,   1 Aug 22 18:29 /dev/console
>> >
>> > In the latter case, the device numbers are the default device numbers
>> > for /dev/console, etc.  In the former case, the inodes for
>> > /dev/console, /dev/conin, and /dev/conout are set to the same as
>> > /dev/cons0.  This logic can be found in fhandler_dev::readdir:
>> >
>> > 203   if (cdev->get_major () == DEV_TTY_MAJOR
>> > 204   && (cdev->is_device (FH_CONIN)
>> > 205   || cdev->is_device (FH_CONOUT)
>> > 206   || cdev->is_device (FH_CONSOLE)))
>> > 207 {
>> > 208   /* Make sure conin, conout, and console have the same inode 
>> > number
>> > 209  as the current consX. */
>> > 210   de->d_ino = myself->ctty;
>> > 211 }
>> >
>> > where myself->ctty seems to depend largely on what file types the
>> > stdio handles are attached to.
>> >
>> > When running from cmd.exe, GetStdHandle(...) returns handles to a
>> > character stream--i.e. the console itself.  However, when running from
>> > mintty it returns pipes (specifically, to a pty, probably related to
>> > the call to forkpty in mintty).  In Cygwin (particularly, in
>> > dtable::init_std_file_from_handle) the result ends up being that when
>> > the stdio handles are pipes, the /dev/cons0 device never gets created.
>> > And thus /dev/console and friends never get rerouted to a real device.
>> > This results in errors when trying to access /dev/console directly:
>> >
>> > $ ls -l /dev/console
>> > ls: cannot access '/dev/console': No such device or address
>>
>> /dev/console is an old concept in Cygwin and it was always attached to
>> the current console window, *if* you were running inside a windows
>> console.  It was never implemented for pseudo ttys as used by mintty.
>>
>> The fact that the /dev emulation shows the con devices is a bit
>> disappointing, given that they are basically unusable.  The existence
>> check only checks if GetConsoleCP() returns successfully, but that's
>> true for a pseudo tty as well.  A console is attached to the process
>> anyway.
>>
>> I'll think about the existence check.
>
> I checked in a patch removing the /dev/conin, /dev/conout and
> /dev/console files from /dev if the process is not running from
> a console.  Check out the latest developer snapshot from
> https://cygwin.com/snapshots/

Thanks Corinna, this patch makes sense.  Indeed, the existence check
just using GetConsoleCP() was a problem I had noted as well, and the
main problem for me was simply that /dev/con{in,out,sole} were being
listed under /dev/ at all when not attached to a Windows console (so
that code I had that was looping over /dev/ entries would break).

--
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] TEST RELEASE: Cygwin 2.9.0-0.1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 2.9.0-0.1

I'm planning for a release next week.  Please test.

===

What's new:
---

- New APIs: explicit_bzero, strnstr.

- New APIs: pthread_mutex_timedwait, pthread_rwlock_timedrdlock,
pthread_rwlock_timedwrlock.

- New API: renameat2.


What changed:
-

- Improved implementation of .

- strptime(3) supports %s (seconds since Epoch) now, analogue to strftime.


Bug Fixes
-

- Fix a regression in fflush introduced in 2.8.0.
  Addresses: https://sourceware.org/ml/cygwin-apps/2017-07/msg00041.html

- Fix a regression in reparse point handling introduced in 2.8.1.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00114.html

- Fix a potential resource leak when checking reparse points during readdir.

- Fix select and read in Windows console when running under codepage 65001.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00388.html

- Fix a clear screen issue in Windows console when running under codepage 65001.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00430.html

===


Thanks,
Corinna

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

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

TEST RELEASE: Cygwin 2.9.0-0.1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 2.9.0-0.1

I'm planning for a release next week.  Please test.

===

What's new:
---

- New APIs: explicit_bzero, strnstr.

- New APIs: pthread_mutex_timedwait, pthread_rwlock_timedrdlock,
pthread_rwlock_timedwrlock.

- New API: renameat2.


What changed:
-

- Improved implementation of .

- strptime(3) supports %s (seconds since Epoch) now, analogue to strftime.


Bug Fixes
-

- Fix a regression in fflush introduced in 2.8.0.
  Addresses: https://sourceware.org/ml/cygwin-apps/2017-07/msg00041.html

- Fix a regression in reparse point handling introduced in 2.8.1.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00114.html

- Fix a potential resource leak when checking reparse points during readdir.

- Fix select and read in Windows console when running under codepage 65001.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00388.html

- Fix a clear screen issue in Windows console when running under codepage 65001.
  Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00430.html

===


Thanks,
Corinna

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

[newlib-cygwin] cygwin: document %s support in strptime

[Corinna Vinschen]

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

commit 4dfaef81414f006377ed235a995c7b2d8dcdcb95
Author: Corinna Vinschen 
Date:   Tue Aug 29 11:16:13 2017 +0200

cygwin: document %s support in strptime

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.9.0 | 2 ++
 winsup/doc/new-features.xml | 4 
 2 files changed, 6 insertions(+)

diff --git a/winsup/cygwin/release/2.9.0 b/winsup/cygwin/release/2.9.0
index 0fff763..6b1f0f2 100644
--- a/winsup/cygwin/release/2.9.0
+++ b/winsup/cygwin/release/2.9.0
@@ -14,6 +14,8 @@ What changed:
 
 - Improved implementation of .
 
+- Add %s support for strptime..
+
 
 Bug Fixes
 -
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index 9bdb94c..4f1ff97 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -25,6 +25,10 @@ New API: renameat2.
 Improved implementation of elf.h.
 
 
+
+strptime(3) supports %s (seconds since Epoch) now, analogue to strftime.
+
+