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
