My review of the C standard library in practice
nullprogram.com
My review of the C standard library in practice
1–10 of 94 posts
Re: My review of the C standard library in practice
#2This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.
Re: My review of the C standard library in practice
#3Discussion yesterday: https://news.ycombinator.com/item?id=34752400
Re: My review of the C standard library in practice
#4This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.
So one should focus on creating versioned API IMO. Nobody does that for some reason. I should be able to declare my program to use v2023 API and consume libraries which use v1975 API.
Re: My review of the C standard library in practice
#5This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.
So one should focus on creating versioned API IMO. Nobody does that for some reason. I should be able to declare my program to use v2023 API and consume libraries which use v1975 API.
Rust kind of does this. Language feature uses "edition" and has crates for its standard api instead of built in.
Re: My review of the C standard library in practice
#6This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.
So one should focus on creating versioned API IMO. Nobody does that for some reason. I should be able to declare my program to use v2023 API and consume libraries which use v1975 API.
That doesn't work in languages with nominal types, and even structurally-typed languages can have a hard time.
You call a function that returns a v1975/SomeStruct and pass it to a function expecting a v2022/SomeStruct. What does the new function do when some of the struct fields are set to invalid values?
Re: My review of the C standard library in practice
#7>Without libc you don’t have to use this global, hopefully thread-local, pseudo->variable. Good riddance. Return your errors, and use a struct if necessary.
On contrary you should absolutely use errno, if only to report your IO errors.
Or maybe he never does IO. After all a program that doesn't output anything is likely safer, since these are all evil side effects. I can just see that new programming paradigm: "side effect free programming" taking over the world in storm.
Just based on that gaffe I'm not sure I can take anything else in that post seriously. It's clearly not based on any practical experience.
Re: My review of the C standard library in practice
#8>Without libc you don’t have to use this global, hopefully thread-local, pseudo->variable. Good riddance. Return your errors, and use a struct if necessary. On contrary you should absolutely use errno, if only to report your IO errors. Or maybe he never does IO. After all a program that doesn't output anything is likely safer, since these are all evil side effects. I can just see that new programming paradigm: "side…
It's not a gaffe, it's moving C in a direction that's safer and more like modern languages by removing mutable global state. That's what this means: "Return your errors, and use a struct if necessary."
Re: My review of the C standard library in practice
#9>Without libc you don’t have to use this global, hopefully thread-local, pseudo->variable. Good riddance. Return your errors, and use a struct if necessary. On contrary you should absolutely use errno, if only to report your IO errors. Or maybe he never does IO. After all a program that doesn't output anything is likely safer, since these are all evil side effects. I can just see that new programming paradigm: "side…
He is saying that the design of errno is a flaw and that errors should be returned via other means. Not that you can safely ignore errno.
Re: My review of the C standard library in practice
#10>Without libc you don’t have to use this global, hopefully thread-local, pseudo->variable. Good riddance. Return your errors, and use a struct if necessary. On contrary you should absolutely use errno, if only to report your IO errors. Or maybe he never does IO. After all a program that doesn't output anything is likely safer, since these are all evil side effects. I can just see that new programming paradigm: "side…
Lots of APIs allow reporting of I/O errors without use of an errno-like construct.