gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incompatible compiler option fexec-charset


From: Richard Frith-Macdonald
Subject: Re: Incompatible compiler option fexec-charset
Date: Wed, 7 Dec 2011 15:53:48 +0000

On 7 Dec 2011, at 15:42, Wolfgang Lux wrote:

> Richard Frith-Macdonald wrote:
> 
>>> Richard Frith-Macdonald wrote:
>>> 
>>>> Great idea ... but not what the gcc documentation says ... how would we 
>>>> enforce it on our users?
>>>> The gcc documentation says the source characterset is (by default) 
>>>> whatever the current locale says it is (or UTF-8 if the compiler can't 
>>>> determine it from the locale) ... unless overridden by the 
>>>> -finput-charset=  command line option.  The check sees if the compiler is 
>>>> performing according to those rules (in which case no command line options 
>>>> are needed), or if the compiler supports the options to specify the 
>>>> charactersets (in which case we use those options).  If you don't want the 
>>>> check (either you don't have any non-ascii literals, or you are sure your 
>>>> compiler will be generating UTF-8 output) you can disable it.
>>> 
>>> I guess I must be a bit dumb as I don't get the point you are trying to 
>>> achieve with your configure check.
>>> It looks like you want to allow people to work in a, say, Latin-2 
>>> environment, but compile their documents as if they were using the UTF-8 
>>> encoding?
>> 
>> No .. the idea is to let them work in whatever environment they like 
>> (latin-2 is a perfectly good example), but have the *binary*  they produce 
>> contain UTF-8 encoded strings so that the running executable will display 
>> the correct characters.
> 
> In that case I don't understand why you want to add -finput-charset=UTF-8 to 
> the compiler options. This flag changes the interpretation of the *source* 
> file.

That's only used while compiling the base library ... because the base library 
source is guaranteed to be UTF-8 (as David pointed out, that's the *sane* way 
to do things), and we therefore don't want people building the base library 
with an environment which would cause string literals in the source to be 
interpreted as any other characterset.  At present this is unnecessary (as we 
actually only use ascii literals), but it makes the code future-proof.

> In fact, I'd say if the compiler ever succeeds compiling the test example 
> with -finput-charset=UTF-8 then the compiler either ignores the option 
> altogether or it is broken since the ISO-Latin 1 pound character is an 
> invalid character in a UTF-8 encoded file.


The compiler is never asked to build the config test as UTF-8 ... the whole 
point of the testy is to check that the compiler produces UTF-8 binaries when 
given non-UTF-8 source.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]