On 15.12.2019 11:43, sebb wrote: > On Sun, 15 Dec 2019 at 00:52, Branko Čibej <br...@apache.org > <mailto:br...@apache.org>> wrote: > > On 14.12.2019 14:08, sebb wrote: > > On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf > <d...@daniel.shahaf.name <mailto:d...@daniel.shahaf.name> > > <mailto:d...@daniel.shahaf.name <mailto:d...@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 >
