[PATCH] Adding wcs* and wmem* in libc/string.

[KJK::Hyperion]

At 03.03 03/09/2002, you wrote:
>and the gnu-win32 package from Paul Sokolovsky and a package from "Mikey" 
>and...  Neither of these is based on newlib but you're hardly the second 
>person to think about doing this.

I should have put "second" it in quotes, it was meant to be an ironic reply 
to the parent message's remark that Cygwin is "the only Unix environment 
based on Windows" ("based on newlib" doesn't make much sense to me - isn't 
the "environment" just the syscall layer, and the C runtime just a 
commodity? or at least, it should be...)

>In the meantime, I don't think it makes sense to go to extra effort to 
>accomodate what is, for now, vaporware.  It should be easy enough to make 
>whatever changes you require when you are up to speed with your new 
>platform.  Until then, asking people to take your future plans into 
>account doesn't seem very practical to me, unless we're talking about very 
>trivial accommodations.

this *is* trivial, AFAIK. Even easier now, in fact, since the only platform 
with UCS-2 wchar_t is Cygwin - just default all platforms to UCS-4, and 
make Cygwin the exception, for now. Plus, having everything depend from 
predefined preprocessor macros - when there's alredy an apposite build 
system to take care of this, I should add - is dangerous: I've seen the 
huge patch sent to the FSF to support GNU on OpenNT, you'd be amazed at the 
abuse of "#ifdef __WIN32__"s, and all the wrong assumptions based on that 
(a bit of background: the GNU toolchain for OpenNT was initially 
cross-compiled with Visual C++, that, being a Windows compiler, predefined 
__WIN32__ - without this implying anything about the target host)

>Of course, I admit to some bias in this area.

Same here, of course

>>(not that this really matters.  If my proposal isn't accepted now, you're 
>>going to hear from us again anyway)
>Which is what I'd recommend.  At some point, I assume that hearing from 
>you will just involve patches which you've devised yourself. That seems 
>more practical than trying to direct others to match your future requirements.

don't confuse discussing a design choice with exploiting others' work. I 
just said that "2 byte wchar_t <=> Cygwin", IMHO, is a substantially wrong 
assumption - there's nothing particularly "Cygwiny" in 2-byte wchar_t's, 
nor "Cygwinness" implies a particular wchar_t width