On 15.12.2019 11:43, sebb wrote:
> On Sun, 15 Dec 2019 at 00:52, Branko Čibej <brane_at_apache.org
> <mailto:brane_at_apache.org>> wrote:
>
> On 14.12.2019 14:08, sebb wrote:
> > On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf
> <d.s_at_daniel.shahaf.name <mailto:d.s_at_daniel.shahaf.name>
> > <mailto:d.s_at_daniel.shahaf.name <mailto:d.s_at_daniel.shahaf.name>>>
> wrote:
> >
> > sebb wrote on Sat, 14 Dec 2019 09:12 +00:00:
> > > The only documentation I could find [1] defines a key using
> > <text-char>:
> > >
> > > <text-char> ::= (any character except <LF>)
> > >
> > > However the character domain is not specified as far as I
> can tell.
> >
> > I don't know where you're quoting that from. It's not on
> the linked
> > page or anywhere else that I can find. It's also patently false
> > because '=' and ' '
> > can't be parts of a group name, because if they were then
> «@foo =
> > rw» would
> > be misparsed.
> >
> >
> > I should have been clearer.
> > I did not mean that a key consists of text-char only.
> >
> > The key is defined in BNF in the Formal Definition section (once
> opened).
> > Follow the BNF through, and one of refs is <text-char>:
> >
> > key => key-cont => key-char => text-char
> > (where => means refers to)
> >
> > i.e. the key definition uses text-char.
> >
> > So in order to know what is allowed in a key, one needs to know
> what a
> > character is.
>
> So what exactly is missing from the definition: "any character
> except <LF>"?
>
>
> The character set.
We don't define that, on purpose, as I already explained.
> Is it ASCII or UTF-8 or something else?
I explained that, too.
> Can one use CR, NUL or DEL in keys?
I don't know. Probably. There's no code that I'm aware of that would
prevent you from using them.
Well, NUL would very likely cause problems since the implementation
relies on C string semantics. Good catch.
> Have such characters been tested?
No. The idea is that these are normal text files. If you have a
particular need to use bytes that are not normal in text, feel free to
test them and report your findings here.
>
> Subversion doesn't define the source character set. It does implicitly
> expect it to be a superset of ASCII, and uses UTF-8 internally. That
> document intentionally doesn't define what a "character" is except for
> special codes that the parser recognizes as delimiters, depending on
> context.
>
> -- Brane
>
Received on 2019-12-15 14:49:57 CET