[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.11

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Thu Aug 25 14:46:00 GMT 2016


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



More information about the Cygwin mailing list