That carriage return that Windows sneaks in there has been the source of a lot of file-parsing problems for me when I forgot to catch that in my programs, because I develop on Linux and I’m not expecting it.
Different OSes using different line endings is such a long standing and well known problem that I would only describe the bugs that come as a result as bad programming. Not even lazy programming, a lazy programmer uses a library that abstracts away these differences.
I program embedded devices. There’s not often just a ready to go library for what you want to do when you’re doing bare metal. You’re given a C compiler with the bare minimums, and that’s it. You’re expected to mostly build what you need by yourself. That includes file-parsing routines. A microcontroller doesn’t even have any idea what a filesystem is unless you build one. I gotta do all that myself with an SD card through low level SPI stuff.
On general purpose OSes, yes, you have a plethora of frameworks and libraries to choose from. In this world, the cool stuff, like C++ Boost libraries for example, doesn’t exist.
On embedded devices, how often are you parsing input that came from notepad (or any other text editor)? If your device has a UI or a web server, you’re likely already using something that handles various encoding and line endings. If you’re reading data you included at build time, consider a validator/sanitizer script that can run in your build environment where it can have easy access to off the shelf libraries.
On a side note- as a software engineer who primarily works on things running in a general purpose OS but does occasionally have to make small programs that can function on embedded devices (albeit still usually with an OS, think routers and iot), I’m glad that the Rust community takes no-std development seriously. Large swaths of the rust ecosystem is available even in embedded environments.
That carriage return that Windows sneaks in there has been the source of a lot of file-parsing problems for me when I forgot to catch that in my programs, because I develop on Linux and I’m not expecting it.
Different OSes using different line endings is such a long standing and well known problem that I would only describe the bugs that come as a result as bad programming. Not even lazy programming, a lazy programmer uses a library that abstracts away these differences.
I program embedded devices. There’s not often just a ready to go library for what you want to do when you’re doing bare metal. You’re given a C compiler with the bare minimums, and that’s it. You’re expected to mostly build what you need by yourself. That includes file-parsing routines. A microcontroller doesn’t even have any idea what a filesystem is unless you build one. I gotta do all that myself with an SD card through low level SPI stuff.
On general purpose OSes, yes, you have a plethora of frameworks and libraries to choose from. In this world, the cool stuff, like C++ Boost libraries for example, doesn’t exist.
On embedded devices, how often are you parsing input that came from notepad (or any other text editor)? If your device has a UI or a web server, you’re likely already using something that handles various encoding and line endings. If you’re reading data you included at build time, consider a validator/sanitizer script that can run in your build environment where it can have easy access to off the shelf libraries.
On a side note- as a software engineer who primarily works on things running in a general purpose OS but does occasionally have to make small programs that can function on embedded devices (albeit still usually with an OS, think routers and iot), I’m glad that the Rust community takes no-std development seriously. Large swaths of the rust ecosystem is available even in embedded environments.