This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Compile performance of Linux kernels in mainline gcc


On Sat, Oct 30, 2004 at 04:49:53PM +0200, Giovanni Bajo wrote:
> Andi Kleen wrote:
> 
> >>> Quotes? You mean >>"<< ?  That is 7 bit ASCII too.
> >>
> >> The world has moved on.  Not every quote character is an ASCII quote
> >> character.  You requested UTF-8, you get it.
> >
> > And what advantage does it have to use such a weird quoting character?
> > Is there anything wrong with the good old ASCII " ?
> > For me this sounds just like a totally unnecessary gratuious
> incompatibility.
> 
> If you use GCC in plain English with plain ASCII, it is just a matter of
> setting your own computer requesting that with the LC_* flags.
> 
> Others may like GCC in Chinese with UTF-8, so they would set their locale
> flags to Chinese UTF-8, and they will get Chinese translations using proper
> Chinese quotes. Notice also that they would write their variable names in
> Chinese UTF-8 as well, and they would expect GCC to compile them correctly,
> and emit them correctly in the error messages.

Well, but I didn't set my Terminal to Chinese. 

But using UTF-8 quotes in a English (or other Latin) locale even when UTF-8 
is enabled doesn't make any sense. It's just an unnecessary source of errors
and a waste of bytes (why encode something in 3-4 bytes when a single byte
works just fine and is more compatible too?) 

> You can't really blame GCC for adding new i18n features: if you have a
> wrongly configured terminal, you get what you ask for.

I don't see how using UTF-8 quotes in a English locale is an i18n
feature. It more looks like a i18n bug to me.

> Anyway, this shows that we probably needs to document this within
> http://gcc.gnu.org/gcc-4.0/changes.html.

Better would be to fix this misfeature. Documenting bugs is usually
the wrong solution.

>From your side it doesn't make much sense too, I bet i won't be the 
only one bit by this and you will just get a lot of unnecessary
support queries by keeping this. 

-Andi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]