I wrote an open source library that parses structured data but intentionally left out carriage-return detection because I don’t see the point. It adds additional complexity and overhead for little/no benefit.
To my surprise, a user submitted a bug where the parser wasn’t working and I discovered the cause of the issue was that the data used CR line endings as opposed to LF or CRLF.
Hasn’t OSX been using LF style line-endings since switching over to a unix-based platform?
I know there are applications like Notepad++ where line endings can be changed to use CR explicitly but I don’t see why anybody would want to.
Is it safe to exclude support for the statistically insignificant percentage of users who decide (for whatever reason) to the old Mac OS style line-endings?
Update:
To clarify, supporting Windows line endings (ie CRLF) doesn’t require CR token recognition. For efficiency purposes the lexer matches on a per-char basis. By silently ignoring CR chars, the CRLF token simplifies to LF. As such, the CRLF token itself could be considered an anachronism all its own but that’s not what this question is about.
The last OS that provided system-wide support for CR style line endings was Mac OS 9. Ironically, the only application that still uses it as the default in OSX is Microsoft Excel.
33
There is a good practice where you are “liberal in what you accept, and conservative in what you send”.
In other words, if there is a chance (however small it will be) that someone will give you a cr line ending (and expect it to work correctly) , you’ll need to support it.
TBH, I can’t see how adding CR support would take all that long.
When you see a cr in the lexer peek the next character and if it is a nl, swallow the newline and emit a newline token, if the next character isn’t a nl just emit a newline token and continue.
11
No. CR is not obsolete (defined as “no longer produced or used”). You yourself have provided evidence of that. It is perhaps uncommon, but not obsolete.
As for “is it safe to exclude support” for CR? As you say, it’s not a matter of losing sales, and you can’t support every weird character combination and file format in the world, and only you know your software and user base. So I would say that it would be safe to exclude it if you’re convinced that the support burden of not adding it (as mouviciel explains) does not outweigh the time burden of adding it. But without knowing a lot more about the product and user base I’m not sure how to be any more specific.
2
About laziness: you have to balance:
-
effort in changing code so that CR is safely handled (and then forget about it).
-
effort in explaining to users why the files they were happy with for decades suddenly crash your app, in finding workarounds that they can use without compromising your sales and in asking for arguments and anwsering to comments right here.
It is up to you to decide which path is the laziest.
10
Is it safe to exclude support for the statistically insignificant percentage of users who decide (for whatever reason) to the old Mac OS style line-endings?
Maybe not too many users will detect it, but there’s an elephant in the room: Windows line endings (CRLF). If you support those (I generally do, even though I only use Windows for games), it should be trivial to support the third part of this historic Bermuda triangle.
If you don’t support something like this, you should at least mention it in the documentation (“This is not a bug” style) and how to change files to work with your tool in the simplest possible way (dos2unix for example).
3
There are many serial devices that rely on CR as an end to the data stream before the ETX is sent. It is a convention that will never go away.
I would treat the request as any feature request where you need to weigh the costs against the benefits.
If exactly one person has asked for CR support, maybe it is not necessary. See the below book chapter from 37 signals where they say you should only worry about very popular feature requests.
http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php
1
MS OS’s from MSDOS onward use the combination CR+LF as a line separator (I think mostly because of matrix printers which need them).
So yeah, it’s a bummer, but you still need support for the damned thing.