From: Michael Stefaniuc <mstefani@redhat.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>
Subject: Re: L'\0' handling
Date: Fri, 09 Apr 2010 22:28:55 +0200 [thread overview]
Message-ID: <4BBF8E07.5030306@redhat.com> (raw)
In-Reply-To: <s2m70318cbf1004091307q1f1ec7a6h679452199c9cbf06@mail.gmail.com>
On 04/09/2010 10:07 PM, Christopher Li wrote:
> On Fri, Apr 9, 2010 at 1:57 AM, Michael Stefaniuc<mstefani@redhat.com> wrote:
>> Christopher Li wrote:
>>> On Thu, Apr 8, 2010 at 1:58 PM, Michael Stefaniuc<mstefani@redhat.com> wrote:
>>>> I have looked at the patch but I don't see it handle wchar_t string literals
>>>> like L"Hello World\n".
>>>
>>> That is on purpose. L"Hello worlds" is very questionable.
>> Huh? Care to explain this one? That is a valid wide char string literal
>> in C and sparse doesn't support those. I don't see much point in
>> supporting only wide char literals and not the wide char string literals.
>
> Ah, silly me. I did not realized the nature of this change is to support wide
> char literals. Just look up what wide char string literals is, now I
> have a better
> idea. You are right. We should support both. My previous patch is wrong
> to set the type of wide char string as "long" type.
>
> So L"hello word\n" pointer are incompatible with char * pointer right?
Yes, they are incompatible.
> And the wchar_t is implementation specific. I am wondering should I just
> pick 16 bit or 32 bit in sparse. Maybe just make it compatible with what
> gcc does.
I know only about Windows that has 16bit wide chars; the rest seems to
be all 32bit.
gcc supports -fshort-wchar to have the wide chars be 16bit; primary
consumer of that is mingw; for probably everything else it is useless.
> Obviously, it need more patches to support wide char string literals.
Yeah, that's what I remember from having looked back then at sparse.
Luckily the correct fix for Wine was to remove the wide char literals :)
bye
michael
next prev parent reply other threads:[~2010-04-09 20:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 14:59 L'\0' handling Yura Pakhuchiy
2010-04-08 15:22 ` Michael Stefaniuc
2010-04-08 15:39 ` Yura Pakhuchiy
2010-04-08 15:54 ` Michael Stefaniuc
2010-04-08 20:19 ` Christopher Li
[not found] ` <1270758815.2167.13.camel@yura-tl>
2010-04-08 20:46 ` Christopher Li
2010-04-08 20:58 ` Michael Stefaniuc
2010-04-08 23:18 ` Christopher Li
2010-04-09 8:57 ` Michael Stefaniuc
2010-04-09 20:07 ` Christopher Li
2010-04-09 20:28 ` Michael Stefaniuc [this message]
2010-06-18 0:30 ` Christopher Li
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=4BBF8E07.5030306@redhat.com \
--to=mstefani@redhat.com \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.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.
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).