Re: Incompatible compiler option fexec-charset

[David Chisnall]

On 7 Dec 2011, at 17:12, Richard Frith-Macdonald wrote:

> 
> On 7 Dec 2011, at 16:43, David Chisnall wrote:
> 
>> On 7 Dec 2011, at 16:04, Richard Frith-Macdonald wrote:
>> 
>>> 2. The reason is that we now support non-ascii string literals for 
>>> compatibility with OSX.  Of course we don't use it ... because we didn't 
>>> support it before.
>> 
>> We don't support string literals at all!  The compiler supports them, not 
>> us.  If we are not using them, then we don't need this configure check (and 
>> a configure check that can safely be disabled and ignored is a pointless 
>> check anyway - reducing the number of executable configure checks, rather 
>> than expanding them, is also a good idea because they break cross 
>> compilation).
>> 
>> So I still don't understand why we have this.  As far as I can tell, 
>> removing it has no adverse effects, enabling it means that I now need to add 
>> an extra flag to configure and people keep appearing in the Étoilé SILC 
>> channel and asking me if I know why GNUstep is broken.
> 
> I did ask for volunteers, and said I didn't like writing autoconf tests and 
> didn't want to do this, and suggested possibly going though and documenting 
> the problem thoroughly to warn people ... but no response.  Which is why I 
> ended up having to go ahead and do it.   I guess the fact that you don't 
> understand it means that, 1 it needed doing and 2 it still needs doing better.

I think you got no volunteers because, as far as anyone else was concerned it 
was already working, -fexec-charset was not required, and there was no clear 
explanation of why it would be required.  The consensus on the list was that 
-fexec-charset=utf8 was a solution in search of a problem and that the correct 
thing to do was to remove it, not add a configure check.

> Anyway, I'll try to be clear/simple ...
> 
> Start with the premise that GNUstep is for users:  developers who write ObjC 
> code 9and we particularly target developers coming from OSX).  It's not for 
> *us* (except in as much as we are users of the code as well as its 
> maintainers).  So whether *we* are using a feature inside GNUstep has no 
> direct bearing on whether *we* support a feature ... the project is not 
> entirely self-referential ... the features we support are primarily for users 
> of GNUstep rather than for internal use by GNUstep.

I am not sure how a configure check *in -base* affects anyone compiling 
anything else.  

If someone is coming from OS X then their source code will be UTF-8 (because 
that's what XCode defaults to and what clang supports).  It will be tested with 
clang (because that's the default compiler on OS X) and the only things 
stopping it from working with clang/GNUstep/Linux will be things related to 
GNUstep and Linux, not things related to the compiler.  But when they try 
compiling base, they get a warning saying 'Your compiler doesn't support a 
thing that you almost certainly don't want it to do.'

> Now, a user of GNUstep may want to use string literals and embed non-ascii 
> characters in them, and expect that when their application displays messages 
> based on those literal strings, the messages should be readable.

If the string literals are in their code, then this depends entirely on how 
they compile their code, not how we compile -base.  

> We support this ... the base library takes the sequence of bytes embedded in 
> the binary by the compiler, interprets it as a UTF-8 string, and makes it 
> into an NSString object which the application is able to display in a 
> readable manner.

This is totally irrelevant to the topic at hand.  Whenever anyone passes an 
array of bytes into the base library, they either specify an encoding or assume 
the encoding for the current locale.  Whether this sequence of bytes is 

> But ... if the compiler embeds something in the binary which is not a legal 
> UTF-8 string than the end user will see rubbish or exceptions will be raised 
> in the app etc.

The only times I've seen that happen have been when the compiler embeds 
something that *is* legal UTF-8 but the current locale is set to C and they've 
used things like stringWithCString: instead of stringWithUTF8String:

> So ... it makes sense for us to check that the compiler is doing the right 
> thing, and if it isn't, we need to warn the user to get them to use a 
> different compiler version or to make sure they avoid non-ascii literals or 
> take whatever other action is needed to ensure that only UTF-8 literals get 
> into the binary ... otherwise they will blame GNUstep for the run-time errors 
> caused by the compile-time failure.

It might make sense, kind of, if we weren't checking something completely 
unrelated to any problem that they are likely to have.  

David

-- Sent from my IBM 1620