On 2/26/2015 3:35 PM, Nicolas George wrote:
> The second issue is that with the windows file API, when the file is opened
> in the so-called "text mode", there is an implicit conversion between '\n'
> in memory (which is actually exactly 0x0A) and "\r\n" in the file; there is
> also a conversion between 0x1A and EOF. It only happens with file I/O
> operations, not with simple string operations, even sprintf. On Unix, a
> similar conversion happens in the TTY layer. The TTY layer is something
> nobody should touch without a long pole and a hazmat suit; on windows, the
> hazmat is littered all over the API.

I read it as a 'text stream', which isn't necessarily file i/o only, but I doubt
it is worth bikeshedding over.

> Therefore, I believe Carl Eugen's original patch was technically correct.

See below.

>> This may also accidentally allow for headers to end with '\n\r\n',
>> wouldn't it?
> 
> Well, the test as it is is half-assed, it checks for a specific common
> mistake but does not actually validate the format of the string.

Yes it's pretty bad, more on that below.

> I am not in favour of fixing the shortcomings of the user's shell in
> FFmpeg's libraries, but if it is considered useful, I believe a more
> complete approach should be used: replace all occurrences of \n with CRLF,
> validate folded headers, etc.

I think relying on the user to input a CR+LF cia command line program is
insane in the first place... shouldn't the library do that / join headers
properly?

- Derek

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to