It's fine to bristle about underhanded evangelism (e.g. "Use Rust instead of C, because C is a foot cannon and Rust is perfect"), but that's definitely not the case here. This is a reasonable critique of the common C pitfalls.
I use C daily. The answer in each category is "I don't know" because, without the additional information provided by a specific ABI, specific target, and specific compiler, these are all undefined. No language is perfect. It's important to understand the limitations of a language to use it effectively. That is closer to the author's point. This is not a condemnation of C, but rather, an acknowledgement of C, warts and all.
The original point of C was to provide a portable low-level language that could capture expressions instead of writing everything in assembler, so that UNIX could be ported to platforms other than the PDP-11. It's also a reason why C still has uses not shared by newer languages, because these newer languages are more precise. This is a Good Thing, but unfortunately, developers who are unaware of this imprecision can make mistakes that aren't portable and may not behave as they assume. These problems appear, seemingly out of nowhere, when porting source code to a new compiler or a new platform. While the examples the author provides are over-the-top and easy for an experienced C developer to catch, there are more subtle examples, such as promotion and signed integer overflow, that are hard even for an experienced C developer to catch.
This is why I use static analysis, model checking, proof assistants, and even a modern compiler with built-in pedantic checking against the standard. This language has subtle corner cases that even someone with 25-30 years of experience can miss. Unit testing can miss these corner cases unless the right input values are chosen, and the right input values are not always so easy to guess. It's not a condemnation of C or an attempt to evangelize newer languages to point this out, but rather, an acknowledgement that mastery of any language means accepting both its strengths and limitations. C has both.
Hello, what would be your recommendations for someone who wants to take the next step from basics of C to contributing to FOSS repos (for ex: FFMPEG or VLC or mpv)?
I have been working my way through [Modern C](https://inria.hal.science/hal-02383654/file/ModernC.pdf) but I can't seem to figure out how does one start with making(/contributing to) non trivial projects.
First, I'm no expert on this. While I do contribute patches to various OSS projects, I'm not an insider in any. I possess some old-school netiquette and I've gone through plenty of commercial projects, so there are enough similarities that allow me to submit patches and get them mainlined from time to time. In other words, please take my advice with an appropriate level of salt, as it may not reflect your experience.
Different projects have different cultures. Some are quite insular and difficult to break into. Others are quite easy going. For instance, I was able to send a patch through Meson's process (a fix to ensure that their CMake compatibility layer could build custom assembler files) in a matter of days. In projects like OpenBSD, in contrast, you really have to impress the core developers and become part of the community before you can make significant changes. Either way, don't get frustrated, and always remember that these projects are more often than not made up entirely of volunteers who don't owe you or anyone else anything. Be gracious and polite with all of your interactions, even when dealing with the more abrasive personalities. Don't take things personally. See every interaction as a learning opportunity.
If you are interested in a particular project, then I recommend joining the mailing lists and forums. Lurk for a while. Learn the organization and politics of the project, as these will differ wildly between projects. Spend time studying the project and offer help to users in the user mailing list. If they have an IRC channel, join it, and ask the developers on the channel how you can help. They will have specific recommendations based on your experience and specific areas that they need help with.
As you study the project, compare the code as-implemented with the documentation, and begin by offering patches to the documentation and manual pages where these differ. Documentation tends to go stale in many projects since much of the "fun" involves writing the code. With developer blessing, consider zooming in on test coverage, if the project values test automation, and find ways to improve it. This will give you a deeper understanding of how the software operates, and it will help you uncover errors (bugs) that require fixing. Many of these will be inconsequential or minor, but as you learn from the developers and community, and participate in tightening up the code base, you will gain practical knowledge, as well as visibility in the community and respect. Furthermore, learning to maintain and fix issues in a mature project is an excellent way to learn how to contribute feature changes that are accepted, since it will challenge you to learn a lot about the code base, project organization, and community.
Pay close attention to how new features are proposed and developed. One thing that is common in many projects is that feature requests that are ambitious are often rejected, unless the person making the request is a known quantity who is willing to put in the work to see the feature through. Minor error reports and feature requests that are laser focused and that come with a well thought-out patch set implementing the feature or fix tend to be much better received. Most projects are willing to take in code that feels like it belongs (follows style, testing, and similar guidelines) and that is well developed. Since you are starting out, don't try to be too ambitious. You'll get a feel over time regarding what feature requests can be accepted, especially if you provide a patch in the request.
All of this being said, in the age of github, where anyone can start a project to scratch a personal itch, also consider creating a minor library that implements something that you care about. Keep this library small and laser focused. Go through the process of getting it to work on Linux, Windows, MacOS, FreeBSD, OpenBSD, NetBSD, etc. Learn about cross-platform build systems, writing man pages, writing documentation, and creating official releases. Try to find friends and colleagues willing to test out the library and provide you with feedback. While this is an open ended suggestion, you can learn a lot on your own about the sorts of problems that you need to solve as an OSS developer by trying your hand at creating and maintaining a small library on your own.
The important thing is to commit to realistic goals and be tenacious. There is a lot to learn, and at times, you will get frustrated. Don't give up. Accept reasonable criticism, but learn to ignore the trolls. Always be open to learning new things, and accept that people get VERY PASSIONATE about this stuff. Heated exchanges and insults are unfortunately quite common in this space. Try to take the high road by being polite, and don't get pulled into a flame war. Certain maintainers seem to like flaming newbies for fun. It's best to avoid those communities entirely, but if you can't, then invest in a good pair of asbestos coveralls.
Good luck, and I sincerely hope that you get involved! The OSS community needs developers, and we all start where you are, more or less.
I use C daily. The answer in each category is "I don't know" because, without the additional information provided by a specific ABI, specific target, and specific compiler, these are all undefined. No language is perfect. It's important to understand the limitations of a language to use it effectively. That is closer to the author's point. This is not a condemnation of C, but rather, an acknowledgement of C, warts and all.
The original point of C was to provide a portable low-level language that could capture expressions instead of writing everything in assembler, so that UNIX could be ported to platforms other than the PDP-11. It's also a reason why C still has uses not shared by newer languages, because these newer languages are more precise. This is a Good Thing, but unfortunately, developers who are unaware of this imprecision can make mistakes that aren't portable and may not behave as they assume. These problems appear, seemingly out of nowhere, when porting source code to a new compiler or a new platform. While the examples the author provides are over-the-top and easy for an experienced C developer to catch, there are more subtle examples, such as promotion and signed integer overflow, that are hard even for an experienced C developer to catch.
This is why I use static analysis, model checking, proof assistants, and even a modern compiler with built-in pedantic checking against the standard. This language has subtle corner cases that even someone with 25-30 years of experience can miss. Unit testing can miss these corner cases unless the right input values are chosen, and the right input values are not always so easy to guess. It's not a condemnation of C or an attempt to evangelize newer languages to point this out, but rather, an acknowledgement that mastery of any language means accepting both its strengths and limitations. C has both.