On 20-Sep-2007, Jan Christoph Nordholz wrote: > Ben: I like the first version of your patch to #437024 - an > explanation of those characters and a change to hexadecimal view > (which I prefer over the decimal representation when dealing with > character sets) really can't hurt.
Thanks for this feedback. If you want to apply just that part,
including the reformatting into a tabular structure as in the latest
versions of the patch, I'd be pleased.
> However I'm reluctant to change the source code's encoding (#439628)
> just because utf is slowly becoming the default. We have already
> diverged a lot from upstream, and I don't want to further this just
> for beauty's sake (and they're slow at accepting patches, even the
> bugfixing ones...).
I'm not really concerned with any files but 'process.c' for this
patch, and UTF-8 makes the most sense there for future expansion of
the digraph table.
The reason for re-encoding all files was for consistency: I thought it
would make most sense to re-encode all files to work with UTF-8 at the
same time; if you disagree, the alternative is to have one file
('process.c') UTF-8 encoded, others encoded differently.
> Besides, the utf characters in help.c and acls.c are part of comments,
> and process.c gets fixed by your patch anyway. IMHO C source should
> ideally be pure ascii.
That's the problem. Once the characters in a file are outside 7-bit
ASCII, the file *must* be encoded using some non-ASCII encoding.
Sticking to UTF-8 seems the most logical choice these days.
However, I can see your point about changing the encoding of an
existing file that upstream may not apply for a while. If you decide
not to re-encode all the source code files at this time, that's your
decision to make.
--
\ "Anyone can do any amount of work provided it isn't the work he |
`\ is supposed to be doing at the moment." -- Robert Benchley |
_o__) |
Ben Finney <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
