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.

"are simply wrong" and "under any reasonable compiler" don't mix - yes, for arm(32/64)/x86(-32 or -64) there are common values, but that doesn't make everything else not exist. OP doesn't say that the first two are UB, just that you don't know what they will be without additional information.

For example, here's a GCC-supported target that's available on Compiler Explorer, where the result of question 1 is "3", and question 2 is "1": https://godbolt.org/z/MjT8YhrTc

Sure, that's an AVR platform where structs are packed and ints are 16 bits, and it returns the size of the struct, in other words, the correct answer. And that's my point, it returns the size of the struct, it's not "don't know", it's not doing anything weird, so why have the question?

But, thus, upon seeing the program, without additional information you cannot know whether it'll give 8 or 3 (or who knows what else), and thus "I don't know." is very much an appropriate answer. Of course, it might be more clear to say "it depends" or "there isn't enough information to answer", but I'd say "don't know" is nevertheless a correct answer. Definitely more correct than "8" at least.

"it's not doing anything weird" only to people who do already know the C standard inside out. But there is a significant amount of people who might not know everything C (or might know that there are some weird things about types, but still assume 'int' will be at least 4 bytes or something).

It's of course not a question of much practical impact (for anyone not working in embedded at least) but it's nevertheless one that can be at least interesting to some.

The only time you're writing sizeof(x) is when you want to know the size of 'x', eg. to store it somewhere else or zero out the memory or something of that sort. And it gives the right answer, great! It doesn't ever do something that's undefined or strange, and it's not an obscure part of the C language.

It seems like you're responding to something that isn't there -- an accusation along the lines of "... and therefore C is a bad language" or "... and therefore sizeof is poorly designed" or "... and it's bad that the correct answer is 'I don't know'".

The author isn't, so far as I can tell, making any such claim.

He's claiming only this: many people who program in C (or C++, which in this particular respect is the same) think they know that sizeof(...) will be 8, or think they know that sizeof(...) will be 5, and all those people are wrong, because it could be either of those things or various other things too, and there are contexts in which you need to be aware that the assumptions you're inclined to make around this sort of code are wrong.

All of which is straightforwardly correct, so far as I can tell.

As the author says, the question is really about struct padding more than it's about sizeof. It most likely doesn't matter that much whether or not someone knows that sizeof(...) might not be 8 in this situation. But it might matter if, e.g., they read the docs for some binary file format and see that it looks like

  offset type   name
  0000   int    block_size
  0004   char   record_type
  0008   int    user_id
  000C   int    unit_id
  0010   double radiation_level
  0018   int    timestamp

and think "aha, I'll make this neater" and write

  struct protocol_block {
    int block_size;
    char record_type;
    int user_id;
    int unit_id;
    double radiation_level
    int timestamp;
  };

and

  fread(...);
  struct protocol_block * block = buffer;
  int uid = block->user_id;

without being aware that they are making assumptions about what their compiler does with structs (and also about endianness, and other things).

You originally said:

> The first case, for example, returns 8 under any reasonable compiler

That is wrong. This part of C is apparently obscure enough that people make false assumptions like your own I quoted.

After you made that claim, someone provided a case where GCC returns something other than 8 and you edited your statement. Again, your statement was incorrect until you edited it, and so there must be some obscurity involved.

sizeof isn't an obscure part of the language, yes, but the specific behavior here might still be unexpected for a decent number of people, who might, say, think they can always use "sizeof(int)" and "4" interchangeably to shorten code (which could very well be true for all platforms they will ever care about, but nevertheless is not a guaranteed property by C by itself).

I am old. I remember when sizeof(int) was usually 2. And I may live long enough to see sizeof(int) typically be 8.

The 16-to-32 bit transition broke a lot of code that assumed sizeof(int) was 2. The next transition may do the same. (Or, we may keep "int is 32 bits" forever, and use long for 64. Who knows? I don't. You probably don't, either, so don't assume that sizeof(int) = 4.)

The present behavior on normal 32-bit and 64-bit platforms is that, on both, 'int' is 4 bytes, and 'long long' is 8 bytes; and on 64-bit, whether 'long' is 4 or 8 bytes depends on the ABI/target OS.

I'd imagine it's quite likely that 'int' stays 4 bytes even on hypothetical 128-bit CPUs - there's not much reason to change it, as on 64-bit it's already less than the CPU width, and thus is pretty much arbitrary even today. But yes, anything that wants a 4-byte/32-bit integer should just use <stdint.h>'s int32_t.

> But, thus, upon seeing the program, without additional information you cannot know whether it'll give 8 or 3 (or who knows what else), and thus "I don't know." is very much an appropriate answer.

May it is appropriate, but its underhanded.

I mean if someone gave the single line of Go code:

     s := x + y

And then, when you said "that adds two number", the someone replied "Hah! Gotcha! The answer is 'I don't know'"

It's puerile.

I don’t get what you’re saying - what’s underhanded about saying structure packing can have unexpected results across platforms, architectures, compilers and even compiler flags?

The point is that you could only ever say for sure what the answer will be if all that is exactly specified, otherwise your assumption could be wrong.

Many errors have arisen from someone tacitly assuming what "any reasonable compiler" would do. These questions barely scratch the surface of the possibilities.

Furthermore, just because your code works with Reasonable Compiler 1, it does not mean it will work with Reasonable Compiler 2. I think I have seen enough C compilers that, for each of these questions, you could pick a pair giving different answers.

Worse, Reasonable Compiler 1 may give different results, depending on what flags you pass it at compile time.

Your code dictates the compiler's behavior. If you grant the compiler flexibility, it's unreasonable to complain about unexpected results.

I don't think it is a complaint; it's an observation in support of a point of view.

I have debugged a problem that was due to a left shift of 1ULL by 64 (in a routine that tried to set the lowest n bits by shifting 1 left and subtracting by 1). I needed to read the Intel docs to find out what actually happens to work out how badly we’d corrupted the customer data and how to write a fix to unmangle it.

What Intel processors do is ignore the upper bits of the shift quantity, so it’s effectively (1ULL << (x % 64)) - 1, therefore the function that should have set all ones for x=64 actually set all zeros.

I understand where you're coming from, but have you tried them? I think there's a good chance the first question will return 16 on 64 bit systems.

Returns 3 on Borland Turbo C, which I think most people would say is a reasonable compiler.

Depends on the ABI which the compiler targets. The vast majority of 64-bit OS's are ILP32, LLP64 or LP64, where ints are 32-bit - but to the paper's point, you don't know until you compile it.

I got the first example to give 4 and the second one returns 1. OpenWacom DOS 16Bit. Under 32bit it gives 8 AND 0.

That's an illustrative example. You're not meant to actually use such code, but the relevant insight (that code with binary shifts is rarely portable with types of unspecified size) is accurate.

You can't say that with certainty without specifying the compiler, it's version, and the architecture.