This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: [PATCH] Adding wcs* and wmem* in libc/string.
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