From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Stefaniuc Subject: Re: L'\0' handling Date: Fri, 09 Apr 2010 22:28:55 +0200 Message-ID: <4BBF8E07.5030306@redhat.com> References: <1270738799.2167.7.camel@yura-tl> <4BBDF4C0.8020305@redhat.com> <1270741172.2167.9.camel@yura-tl> <4BBDFC28.4080304@redhat.com> <1270758815.2167.13.camel@yura-tl> <4BBE4368.4080105@redhat.com> <4BBEEBE9.7030009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19575 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755376Ab0DIU3f (ORCPT ); Fri, 9 Apr 2010 16:29:35 -0400 In-Reply-To: Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Christopher Li Cc: Linux-Sparse On 04/09/2010 10:07 PM, Christopher Li wrote: > On Fri, Apr 9, 2010 at 1:57 AM, Michael Stefaniuc wrote: >> Christopher Li wrote: >>> On Thu, Apr 8, 2010 at 1:58 PM, Michael Stefaniuc 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