"Peter N. Lundblad" <peter@famlundblad.se> writes:
> We have to decide, once and for all, if we support systems with an
> execution character set that isn't ASCII-based (i.e. ASCII is a subset).
> As brane points out, we have other places that use character constants.
> Unless you are going to fix all these, it makes no sense to say 65 instead
> of 'A'. If we want to support EBCDIC and such, we should define symbolic
> constants instead of spreading these numbers all over the code.
Obviously, if these numbers ever start appearing elsewhere, we'll
abstract things out. When they're only in one function, there's no
point creating named constants, it would only obscure.
Re the larger question, that is essentially what I was opening in the
thread entitled "using isalpha/isalnum in locale-independent code", so
maybe follow up there?
I realize there are two unrelated questions going on: the question of
locale, and the question of execution character set (i.e., ASCII vs
EBCDIC). If we decide to support ASCII only, then r12029 can be
tweaked to use character constants instead of numbers, but it can't go
back to using isalpha()/isalnum().
> An aside: why limit property names to ASCII? Is there a reason other than
> "it is simple for now"? Else, I'll file an issue about supporting the
> whole Name production in XML 1.1. (Or do we have to stick to XML 1.0?)
Yeah, I don't know why we're limiting property names to ASCII, except
perhaps that it's easy to implement (basically I was just trying to
make the function do what it claimed to do -- not trying to change the
claim itself :-) ). +1 on the issue, though realistically I wonder
when we'd get around to doing anything about it, as it's probably not
a showstopper for any users.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 26 02:51:04 2004