[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20150508130145.dc30d64f61e5ec441c34ffd4f788e58e.31f81ebf87.wbe@email15.secureserver.net>
Date: Fri, 08 May 2015 13:01:45 -0700
From: <writeonce@...ipix.org>
To: musl@...ts.openwall.com
Subject: RE: There is no tests for musl,
On 05/08/2015 11:41 AM, 罗勇刚(Yonggang Luo) wrote:>>>> solution, I
think there is no one would use
>>>> wchar_t for cross text processing, cause, on some system, wchar_t is
>>>> just 8bit width!
>>>
>>> anybody would use wchar_t who cares about standard conformant
>>> implementations.
>>>
>>> non-standard broken platforms may get an unmaintained #ifdef
>>> as usual..
>>
>> I think we (and midipix) have a different perspective from Yonggang
>> Luo on portable development. Our view is that you write to a POSIX (or
>> nearly-POSIX) target with fully working Unicode support and fix the
>> small number of targets (i.e. just Windows) that don't already provide
> Small is relative, if counting the distribution count, well, Unix wins.
>> these things. Yonggang Luo's perspective seems to be more of a
>> traditional Windows approach with #ifdef and lots of OS-specific code,
>> but just making the Windows branch of the #ifdefs less hideous than it
>> was before. :)
> If getting wchar_t to be 32 bit on win32, then truly will be a lot of
> #ifdef, I am not so sure
> if you have experience on Win32 API development, I hope we discussing
> the problems in a
> more objective way.
>
One primary objective of code portability and posix-compatibility layer
for win32 is to _remove_ the need for OS-specific code-paths. A wchar_t
that is anything short (no pun intended) of a 32-bit integer will render
it impossible to build out of the box many pieces of commonly-used
software, including, but not limited to musl libc, the curses library,
and anything that expects wchar_t to cover the entire unicode range.
As for your suggested framework: there are currently at least three
compilers that can produce optimized code for the target platform (gcc,
clang, and cparser), and which work very well with most open-source
software out there. As an aside, if you are interested in an 8-byte long
on 64-bit windows then an open-source compiler is probably your only
option. To compile musl with msvc, on the other hand, you'd have to make
so many changes to the source code that you might as well write your own
libc from scratch. To see why, please attempt to compile some ten or
fifteen core libc headers (stdio.h, unistd.h, etc.) with msvc. If that
goes well (spoiler: it won't), then the next step would be to compile a
subset of the source files (src/pthread or src/stdio, for instance) and
remove any remaining obstacles.
m.
>>
>> Rich
>
>
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
