[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] issue #2147 - v1

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-01-30 00:13:39 CET

On Fri, 28 Jan 2005, VK Sameer wrote:

> Peter N. Lundblad wrote on 01/26/2005 12:29 PM:
> > On Wed, 26 Jan 2005, Julian Foad wrote:
> >
> >
> >>(2)
> >>Now I'm confused about what you are escaping. You are escaping all ASCII
> >>control characters (as defined by svn_ctype_iscntrl). That includes valid XML
> >>characters CR, LF and TAB. Shouldn't you be escaping only non-XML control
> >>characters?
> >>
> >
> > And non-ASCII invalid XML characters as well (in the future, when we have
> > functions to convert to Unicode scalars). Could you design the function so
> > it can be extended for that later? (Thinking of the API, not the
> > implementation.)
> >
>
> Sorry, Peter, I don't think I understood.
> Unless you mean accepting a set of bytes instead of a single char?
>
You mean my message was somewhat cryptic? Can never be that way;) Hmmm,
maybe.

What I mean is that what you want to do is eliminate characters that can't
be represented in XML, and you want to specify that in the docstring. As
Julian points out, this is not the same as ASCII control characters. I
think you should drop using svn_ctype.h functions for this purpose and
just list the invalid characters in the function in some way.

Also, note that XML lists FFFE and FFFF as invalid in XML. I am not sure
that these can be represented in vaid UTF8, but if they can, you ideally
should handle them too. (XML also excludes the surrogate characters, but
they are forbidden by UTF8 anyway). So, FFFE and FFFF was the non-ASCII
part.

Hope this clarifies,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 30 00:14:27 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.