27

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.

Improve this question
33
  • 21
    "It adds additional complexity and overhead": I think the additional complexity and overhead are really small.
    – Giorgio
    Dec 13, 2012 at 7:10
  • 11
    @EvanPlaice wouldn't it give less headaches and more time to be lazy to just plug in the CR support you intentianlly left out?
    – Pieter B
    Dec 13, 2012 at 7:50
  • 11
    "In business terms the opportunity cost is too high. In simple terms, I'd rather find reasons to justify my laziness than waste time adding edge-case support for a dead platform.": In business terms it would have taken less time to implement the support for CR than to post a question here to investigate the relevance of this feature.
    – Giorgio
    Dec 13, 2012 at 9:03
  • 4
    @EvanPlaice cultural inertia is perfectly good reason.
    – Pieter B
    Dec 13, 2012 at 9:06
  • 5
    @EvanPlaice: Writing this question already cost you more of time than simply shoveling in support for CR newlines into your codebase. (...and if you firmly believe this isn't the case, your parser's design must be pretty hectic)
    – ZJR
    Dec 13, 2012 at 10:54

7 Answers 7

Reset to default
37

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.

Improve this answer
11
  • 24
    @ZJR: postels law is dangerous: be very careful when employing the robustness principle, because it frequently backfires. The html parsing mess we are still in can be attributed to that mindset. When a program accepts malformed input, its behavior as a result soon becomes expected and depended upon behavior, and any changes later that treat the malformed input differently, or not at all, while being technically correct, is often considered defective.
    – whatsisname
    Dec 13, 2012 at 16:18
  • 4
    @whatsisname: I disagree. I think production quality software should be robust. Development toolchains should however strongly discourage relying on such robustness and only produce valid output. The mess html is in is caused by almost two decades of poor tooling, not by the lenience of browsers.
    – back2dos
    Dec 13, 2012 at 16:50
  • 2
    @back2dos: _ _ so? the poor tooling is caused by the lenience of browsers.
    – amara
    Dec 13, 2012 at 19:31
  • 4
    the poor tooling is the result of the browser war
    – ratchet freak
    Dec 13, 2012 at 19:44
  • 2
    @Dibbeke: Handling malformed input merely maps a bigger input space to the existent state space and thus has no effect on it - provided your software has a decent separation of concerns.
    – back2dos
    Jan 9, 2013 at 16:02
21

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.

Improve this answer
2
  • 13
    +1 - IMO, the OP is trying to label CR as "obsolete" so that he has an excuse for not supporting it.
    – Stephen C
    Dec 13, 2012 at 11:20
  • 1
    @StephenC I'm not trying to hide that fact. It's not like I really need an excuse, I'm the author and thus have final say. The point is, it raises an interesting question.
    – Evan Plaice
    Dec 13, 2012 at 22:18
18

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.

Improve this answer
10
  • Good points, support definitely comes with a time cost. For this particular case 'sales' isn't an issue (ie it's open source) but it's worthwhile to consider the bigger picture. Likewise, I could also throw an exception in the code when a CR is encountered indicating an invalid/unsupported character.
    – Evan Plaice
    Dec 13, 2012 at 9:41
  • 7
    @Evan: Of course it's open source. If it weren't, your boss would have told you "I don't give a shit that 'nobody' uses CR anymore! Customers are complaining. FIX IT!" :P This is the big thing about OSS that pisses me off: the lack of attention to the real cases that users have complained about. Whether you think it's obsolete or not, someone is still using it.
    – cHao
    Dec 13, 2012 at 13:25
  • 1
    because it's open source, you can write an open letter to all users that you will accept any patch to fix it.
    – rwong
    Dec 13, 2012 at 19:12
  • 1
    @EvanPlaice: That "attention is...currency" thing works both ways. If you want people to use your app, it has to work, and it has to solve their problem. A broken app isn't immune to criticism just because it's free. I'm not saying you need to do everything users ask for; you should dismiss outrageous requests. But if you don't solve real users' problems, you end up losing users.
    – cHao
    Dec 13, 2012 at 23:54
  • 1
    @EvanPlaice: And by the way, when i mean "complain", i mean "file a bug report outlining what's broken and how", not "whine randomly about how bad the software is".
    – cHao
    Dec 14, 2012 at 4:19
8

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).

Improve this answer
3
  • 2
    +1 for mentioning Windows using CRLF - it's the default line ending on that OS. And there's no way to guarantee the source of a .csv file, so it easily could have been created on a Windows system.
    – user53019
    Dec 13, 2012 at 14:44
  • 1
    Mentioning CRLF in Windows isn't relevant because if you are catching LF as the break point then you'll automatically get CRLF as a bonus. The OP knows this as you can see in the text of his post.
    – davidethell
    Dec 13, 2012 at 20:31
  • @davidethell Yep, that's how it's done. Currently, CR chars are silently ignored. Elephants notwithstanding.
    – Evan Plaice
    Dec 13, 2012 at 22:39
6

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.

Improve this answer
3

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

Improve this answer
1
  • 1
    Finally, a good counter-point. If I could select two answers I'd pick this one too.
    – Evan Plaice
    Jan 8, 2013 at 23:32
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.