From: "罗勇刚(Yonggang Luo) " <luoyonggang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
James McNellis
<james-5OgNh6/BCtVKcNVKSCbDRAC/G2K4zDHf@public.gmane.org>,
austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org,
Clang Dev <cfe-dev-Tmj1lob9twqVc3sceRu5cw@public.gmane.org>,
blees-x8bNZE/nUJk@public.gmane.org,
dplakosh-etTNj8cnB6w@public.gmane.org,
hsutter-0li6OtcxBFHby3iVrkZq2A@public.gmane.org,
writeonce-noBqTzJW0ZJAfugRpC6u6w@public.gmane.org
Subject: Is that getting wchar_t to be 32bit on win32 a good idea for compatible with Unix world by implement posix layer on win32 API?
Date: Sat, 9 May 2015 11:16:37 +0800 [thread overview]
Message-ID: <CAE2XoE_vO83dVqmJ3xRb9md8H=EO0j723Ycwqijo1To88iGueA@mail.gmail.com> (raw)
Two solution:
1、Change the width of wchar_t to 16 bit, I guess that would broken a
lot of things that exist on Win32 world.
2、Or we should preserve wchar_t to be 16 bit on win32, and add the
char16_t and char32_t
variant API for all API that have both narrow and wide version?
I support for the second one, even if the second option is not
applicable. the first option would cause a lot problems, the first
thing is all Windows API use wchar_t and dependent on the wchar_t to
be 2 byte width. Second is, there is open source libraries that
dependent the de fac·to that wchar_t to be 16 bit, such as Qt,
Git(maybe).
Almost exist open source libraries that already ported to Win32 are
dependent the the fact wchar_t to be 16 bit, cygwin is also discussed
if getting wchar_t to be 32bit on win32
https://www.cygwin.com/ml/cygwin/2011-02/msg00037.html
> 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
>>
>>
>>
>
>
next reply other threads:[~2015-05-09 3:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-09 3:16 罗勇刚(Yonggang Luo) [this message]
2015-05-09 3:32 ` Rich Felker
2015-05-09 3:36 ` 罗勇刚(Yonggang Luo)
[not found] ` <CAE2XoE_vO83dVqmJ3xRb9md8H=EO0j723Ycwqijo1To88iGueA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-09 7:55 ` John Sully
2015-05-09 10:36 ` [cfe-dev] " Szabolcs Nagy
[not found] ` <20150509103645.GG29035-4P1ElwuDYu6sTnJN9+BGXg@public.gmane.org>
2015-05-09 11:19 ` 罗勇刚(Yonggang Luo)
2015-05-09 20:05 ` Rich Felker
2015-05-10 12:19 ` 罗勇刚(Yonggang Luo)
2015-05-10 12:31 ` 罗勇刚(Yonggang Luo)
2015-05-10 13:42 ` Rich Felker
[not found] ` <20150510134230.GN17573-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2015-05-10 14:15 ` [musl] " 罗勇刚(Yonggang Luo)
2015-05-10 15:30 ` Rich Felker
[not found] ` <CAE2XoE8ARm6BkarKYspPK_uDkePw8PewHXPWRXmT+mGM5mwEaw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-11 1:47 ` [musl] " Mike Frysinger
2015-05-11 3:25 ` 罗勇刚(Yonggang Luo)
2015-05-11 10:27 ` [musl] " Joerg Schilling
2015-05-12 3:21 ` 罗勇刚(Yonggang Luo)
2015-05-10 18:47 ` Karsten Blees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE2XoE_vO83dVqmJ3xRb9md8H=EO0j723Ycwqijo1To88iGueA@mail.gmail.com' \
--to=luoyonggang-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org \
--cc=blees-x8bNZE/nUJk@public.gmane.org \
--cc=cfe-dev-Tmj1lob9twqVc3sceRu5cw@public.gmane.org \
--cc=dplakosh-etTNj8cnB6w@public.gmane.org \
--cc=hsutter-0li6OtcxBFHby3iVrkZq2A@public.gmane.org \
--cc=james-5OgNh6/BCtVKcNVKSCbDRAC/G2K4zDHf@public.gmane.org \
--cc=musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org \
--cc=writeonce-noBqTzJW0ZJAfugRpC6u6w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).