On Jun 7, 2014 12:44 PM, "Richard Hipp" <d...@sqlite.org> wrote: > > Years ago (decades ago, actually), somebody rigged up fopen() so that it did automatic NL <-> CRNL conversions unless you used "rb" or "wb" as the "type" parameter. This seemed like a clever solution at the time and was warmly embraced by many developers. > > However, with the passage of time, this auto-convert-by-fopen idea was found to be a misfeature. An anti-pattern. It lead to a lot of bugs, and a lot of work-around code. It sometimes converts when you do not want it to. It sometimes fails to convert when you do want it to. It is a general nuisance and pain.
I would disagree to this extent: misuse of this feature is a problem, and by extension ignorance of it is a problem (by which I mean those unfamiliar with it, not that you are ignorant of it). It is a platform / portability concern feature, in that if you take pure C run time library based code that uses the C platform standard of newline for EOL markers, you can recompile it without modification and get a program that does the right thing for whatever system (newline on unixen, CRLF for DOS & Windows, CR only on classic Mac systems). They will generate text that can easily be consumed on the platform and will be able to consume text created by other programs that follow the platform's standard EOL convention. I don't agree that the presence of the feature is a problem. If you meant that the way it was implemented (an optional modification to a parameter to fopen) is the misfeature, then I can agree that it would have been better to do it some other way with 20/20 hindsight, but it was a reasonable solution based on existing practice and "standardization" efforts of the 70s & 80s. SDR
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
