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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
