Re: (((buf[idx] == '\n') && ((idx == 0) || (buf[idx-1] != '\r'))) || (buf[idx] == '\r'))
Personally, I'd avoid indexing backwards at all costs and instead I'd be looking ahead. That's exactly how you start breaking stuff, not to mention messing up caches and whatnot.
Not at all difficult to look for CR alone and then ignore any single following LF when dealing with it.
I think it stems more from Notepad used to use a certain type of control that only ever handled plain text and (initially) had a limit of 32Kb, and lived entirely in memory. It then grew up and ended up in Windows 95, but was never really developed on properly. Load a large file in Notepad and you still have to have however-much free RAM to hold the entire file to even look at the first page of it, and wait while it parses it all (do it with a binary and see what happens!). Do the same in anything else and it might decide to parse the whole file (and will handle it like a text file, not just a bunch of ASCII characters) but it probably won't stick it all in RAM over reading from the relevant index as it goes.
I can't even remember the name of the control now, but back in VB 2/3 days you could make your own Notepad in about a minute... it was a textbox control and a couple of menus. Wordpad etc. was very different and required per-line / per-character formatting to be applied programmatically and wasn't subject to the 32Kb limit.
You can still technically open a 2Gb file with Notepad nowadays, but good luck waiting for it.
Biting the hand that feeds IT
