Re: [PATCH v7 10/10] convert: add filter.<driver>.process option

From: Torsten Bögershausen <tboegi@web.de>
Date: Sep 13, 2016, 14:44 UTC
Message-ID: <96554f6d-988d-e0b8-7936-8d0f29a7564f@web.de>
In-Reply-To: <10020380-76ED-4371-A0BA-59D07AF33CE0@gmail.com>

On 12.09.16 11:49, Lars Schneider wrote:

Show 14 quoted lines

>> How do we send pathnames the have '\n' ?
>> Not really recommended, but allowed.
>> And here I am a little bit lost, is each of the lines packed into
>> a pkt-line ?
>> command=smudge is packet as pkt-line and pathname= is packed into
>> another one ? (The we don't need the '\n' at all)
> 
> Every line is a dedicated packet. That's why '\n' in a path name would
> not be a problem as the receiver is expected to read the entire packet
> when parsing the value (and the receiver knows the packet length, too).
> 
> The '\n' at the end is required by the pkt-line format:
> "A non-binary line SHOULD BE terminated by an LF..."
> (see protocol-common.txt)

That is only the half part of the story: A non-binary line SHOULD BE terminated by an LF, which if present MUST be included in the total length. Receivers MUST treat pkt-lines with non-binary data the same whether or not they contain the trailing LF (stripping the LF if present, and not complaining when it is missing).

How do we treat pathnames ? They can have each byte value except '\0'. What should a receiver do, which reads a string like "ABC\n\n" ? Is it "ABC\n" or "ABC\n\n" ?

I would really consider to treat pathnames as binary, and not add a trailing '\n',
are there other opinions ?