linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).