Re^3: Detect line endings with CGI.pm upload

I remember a thread here recently pointing out that \n is not guaranteed to be a line feed, and that the suggested approach approach was to use \x0a and \x0d because you can be sure of their meanings.

I vaguely remember having that problem way back when I was a C programmer.

G. Wade

Comment on Re^3: Detect line endings with CGI.pm upload Select or Download Code

Replies are listed 'Best First'.
Re^4: Detect line endings with CGI.pm upload by ikegami (Patriarch) on Dec 26, 2008 at 23:43 UTC
The only system where \n and \r aren't LF and CR is MacPerl (Perl for old Macs). This has nothing to do with C.	[reply]
Re^5: Detect line endings with CGI.pm upload by gwadej (Chaplain) on Dec 28, 2008 at 20:55 UTC
On Windows `\n` is CRLF, not LF, even in C. This can cause problems when reading and writing files that shold be binary but are written as text and vice versa. Update: as ikegami correctly points out, I was conflating the disk version with the in memory version of these strings. `\n` should always be the line feed (in memory) and the I/O subsystem should have converted it. G. Wade	[reply] [d/l] [select]
Re^6: Detect line endings with CGI.pm upload by ikegami (Patriarch) on Dec 29, 2008 at 00:39 UTC
Not true. `>perl -le"print length qq{\n}" 1 >perl -le"print unpack 'H*', qq{\n}" 0a` [download] Read more... It's not true in C either. (735 Bytes) In Perl, `LF` gets converted to `CRLF` on input/output when the `crlf` PerlIO layer is used. While the string is in memory, you want to work with just `LF`, and `\n` is just `LF`.	[reply] [d/l] [select]