L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit : > This does not necessarily work on windows. The C standard idctates that in > text mode, \n is translated to the system's native newline. > > Use memcpy and 0x0D / 0X0A / 0x00.
I think you are confusing two subtly different issues and getting the result wrong. The first issue is that the C standard does not specify the byte value of '\n' and '\r', the most notable example being macos<10 where '\n' is 0x0D instead of 0x0D everywhere else because apple never does anything like everyone else. But they still translate into a single byte value each, and POSIX specifies that '\n' = 0x0A and '\r' = 0x0D. 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. Therefore, I believe Carl Eugen's original patch was technically correct. > 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. 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. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
