Re: Incompatible compiler option fexec-charset

[Richard Frith-Macdonald]

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.

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.

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