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.