This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.11
On 2016-08-25 02:07, Corinna Vinschen wrote:
On Aug 24 14:47, Brian Inglis wrote:
On 2016-08-24 12:29, Corinna Vinschen wrote:
On Aug 24 11:30, Brian Inglis wrote:
On 2016-08-24 02:22, Corinna Vinschen wrote:
On Aug 23 23:36, Brian Inglis wrote:
On 2016-08-23 22:15, Brian Inglis wrote:
On 2016-08-23 10:11, Corinna Vinschen wrote:
On Aug 23 07:27, Brian Inglis wrote:
Compared lists of locale_t headers and functions for POSIX, Cygwin,
and glibc, attached below for comparison, and found:
* missed string.h(strerror_l) on my first check;
not sure if you can implement that easily on Windows?
* GNU also supports wchar.h(wcsftime_l) and time.h(strptime_l);
* GNU also defines string.h(str[n]casecmp_l) functions as an extension,
as well as in POSIX specified strings.h.
I just applied a couple of patches to add the missing strerror_l,
strptime_l and wcsftime_l. I also added the missing str[n]casecmp_l
prototypes to strings.h. I'll create a new test release in a bit.
GNU duplicates the POSIX strings.h(str[n]casecmp_l) in string.h also.
i.e. str[n]casecmp_l should be defined under #if __POSIX_VISIBLE >= 200809
but not defined under #ifdef __GNU_VISIBLE in string*s*.h,
and defined under #ifdef __GNU_VISIBLE but not defined under
#if __POSIX_VISIBLE >= 200809 in *string*.h;
strerror_l should be under #if __POSIX_VISIBLE >= 200809 in *string*.h,
or its #includes.
They were already declared in string,h.
Sorry for the poor explanation, but what I was failing to say clearly
was that:
* there does not appear to be any strerror_l declaration in string.h
[...]
and that str[n]casecmp_l conditionals __GNU_VISIBLE and __POSIX_VISIBLE >= 200809
appear to be flipped around between string.h and strings.h declarations in:
[...]
Care to send patches to the newlib list? Patches (git format-patch)
rule over descriptions alone :}
Knew there were good reasons I avoided git for a decade!
See https://en.wikipedia.org/wiki/Git_(slang)
Developers never heard of KISS, unlike you folks at Cygwin ;^> and the folks at hg.
git show attached in case my patch email does not get thru or is scrambled some way,
so it does not apply with git am, after my screwing around with git and mailx.
It applied, but I had to make a few changes, see my reply to the
newlib list. What you shouldn't do is to put the entire log
message into one line. The first line of your log message becomes
the subject of your patch email. Keep it short and add the
rest of the log message starting in line 3. Line 2 stays clear,
it separates the subject from the body.
Seems like mailx -t does not handle multi-line subjects and .sig
properly: may have some digging to do there. Other mail clients
do not support plain text attachments: I've used most in Cygwin,
and built mailx from s-nail based on Heirloom, as Heirloom mailx
just failed to email from Cygwin.
You don't need mailx, btw. After you created your patch with
`git format-patch', you can send it with `git send-email' :)
Looked for that, and everything there, but:
$ uname -srvmo
CYGWIN_NT-10.0 2.5.2(0.297/5/3) 2016-06-23 14:29 x86_64 Cygwin
$ git --version
git version 2.8.3
$ man git | fgrep git-send-email
git-send-email(1)
$ git help send-email
No manual entry for gitsend-email
$ git help git-send-email
No manual entry for git-send-email
$ man git-send-email
No manual entry for git-send-email
$ ls -1 /usr/share/man/man1/git* | wc -l
143
$ ls /usr/share/man/man1/git-send-email*
ls: cannot access '/usr/share/man/man1/git-send-email*': No such file or directory
$ git send-email
git: 'send-email' is not a git command. See 'git --help'.
--
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