4 ms·

Any recommendations on static analyzers, unit tests, coverage for c? Can clang tidy give hints about modern c they way it does about modern c++?

cillian64 4y ago
One useful tool is running clang or gcc with —Werror -Wpedantic which will point out a lot of things which are useful to know about, even if occasionally a false positive.
flohofwoe 4y ago
Set warning level to max, use clang static analyzer or clang tidy (I'm not quite sure how those two relate to each other though), and especially ASAN (Address Sanitizer) and UBSAN (Undefined Behaviour Sanitizer) (and if you write threaded code: TSAN (ThreadSanitizer). One thing that Apple did right in Xcode and where other IDEs lagged behind is easy access to those tools from the UI.
- galangalalgol 4y ago
  That sounds like all the things I do for c++. One thing I really like is that clang tidy can flag the "old way" to do stuff. Was hoping it had that for c.
gregfjohnson 4y ago
Not exactly your question, but valgrind is an amazing tool. It does execution-time analysis of your code and provides an in-depth report on memory usage. It will find and report memory leaks, use of uninitialized variables, bad memory references, etc. I love programming in C, but there are a lot of ways to corrupt memory, get segfaults, etc. valgrind is a useful and powerful way to guard against many of these kinds of problems. C++ is no better. The way I see it, programming in C is like lying on a bed of nails. Doable if you are very careful. With C++, they put a sheet over the bed of nails.
- galangalalgol 4y ago
  I haven't used valgrind in years, more used to asan, but I've been told it can do things asan can't? Edit: to stretch the metaphor, modern c++ is like a thick rubber pad on the bed of nails, but often on the job you are hot bunking and you don't know which c++ your predecessor used to make the bed... Or you are in a hurry and you aren't sure which one you grabbed.
  - swinglock 4y ago
    Ideally you use both, as both can find some more obscure issues the other may not. At least in the past. Either in isolation also works well, though Valgrind is really a suite of many tools.
  - mtklein 4y ago
    If you're used to ASAN, think of Valgrind like ASAN, TSAN, MSAN, and UBSAN all at once at the same time, and then has other facilities like profiling. In any situation where I have control of how the code is built, I personally prefer to run those various SANs instead of Valgrind, usually three parallel builds: one with -fsanitize=address,integer,undefined, one -fsanitize=thread if more than one thread is involved in the project, and one -fsanitize=memory too if Linux is available. That gets you almost all the benefits of Valgrind faster than Valgrind. But Valgrind is still an exceptionally powerful tool to learn and use. Its chief advantage to me is to be able to work with an unmodified binary. Its chief downside is it can be slow, and occasionally you may run into issues with support for more obscure instructions like vcvtps2ph. MSAN is really the star of the sanitizer world, and is worth spinning up a Linux VM for. It tracks the initialized-ness of all your data and catches any use (really, branch) on anything uninitialized. I like to think of ASAN as "did I get my pointers right?" and MSAN as "did I get everything else right?". If you're not familiar with integer sanitizer, it's like UBSAN except it checks for things that are often mistakes rather than things that are actually undefined. The most common situation I've found is code that's hashing data will often pop up a warning about unsigned integer overflow, which I choose to suppress as finely grained as possible with something like __attribute__((no_sanitize("unsigned-integer-overflow", "unsigned-shift-base"))). That way you can still find unintentional unsigned integer problems (e.g. with size_t).
sfpotter 4y ago
Don't bother with this stuff (or with "modern C") if you're just beginning to learn the language. You don't need it for small programs. No one is going to yell at you if your first effort isn't perfect. And no one is going to yell at you if you read the "wrong" book, or try things out in the "wrong" order. Pick any learning resource and get started now. You'll probably get distracted and move on to something else. Come back to it later or not.
- galangalalgol 4y ago
  Well C was my second language. I learned it on an amiga 500. But I quickly transitioned to a 386 (yes i know, a downgrade) but my dad put turbo c++ on it and I never wrote much ansi c after that. A bit for odd embedded targets, but mostly c++ my whole career. So I can write old fashioned c, and I don't start new projects in c, but writing c abi shims for c++ libraries or reading modern c is something I do with some frequency. Learning it would be fun maybe as I've never really used c99 or newer for anything.
  - sfpotter 4y ago
    My comment is for the OP, not for you. Go nuts learning C tooling and have fun.
- kaba0 4y ago
  I’m not sure, it does help to even just know about whether your program is faulty, and C doesn’t like telling it you, or in unintuitive ways only.
- seba_dos1 4y ago
  Do bother with this stuff, it's super helpful and helps you understand your mistakes. Writing C without using sanitizers is like playing a game on hard mode, even for simple programs (especially when you're still learning). You may leave static analyzers for later though, since they're more likely to bother you with unimportant stuff - but not much later.
suprjami 4y ago
You can't rely on one tool, different ones catch different things. No one tool is best. I usually use "-Wall -Wextra -Wpedantic", the GCC static analyser "-fanalyzer", cppcheck, and Clang scan-build. That's good enough for my personal projects. I have a couple of blog posts about this: https://superjamie.github.io/2022/05/24/c-static-analysis-tools https://superjamie.github.io/2022/05/24/c-static-analysis-to... https://superjamie.github.io/2022/11/04/c-static-analysis-tools-part-2 https://superjamie.github.io/2022/11/04/c-static-analysis-to...

cillian64 4y ago

One useful tool is running clang or gcc with —Werror -Wpedantic which will point out a lot of things which are useful to know about, even if occasionally a false positive.

flohofwoe 4y ago

Set warning level to max, use clang static analyzer or clang tidy (I'm not quite sure how those two relate to each other though), and especially ASAN (Address Sanitizer) and UBSAN (Undefined Behaviour Sanitizer) (and if you write threaded code: TSAN (ThreadSanitizer). One thing that Apple did right in Xcode and where other IDEs lagged behind is easy access to those tools from the UI.

galangalalgol 4y ago
That sounds like all the things I do for c++. One thing I really like is that clang tidy can flag the "old way" to do stuff. Was hoping it had that for c.

gregfjohnson 4y ago

Not exactly your question, but valgrind is an amazing tool. It does execution-time analysis of your code and provides an in-depth report on memory usage. It will find and report memory leaks, use of uninitialized variables, bad memory references, etc. I love programming in C, but there are a lot of ways to corrupt memory, get segfaults, etc. valgrind is a useful and powerful way to guard against many of these kinds of problems. C++ is no better. The way I see it, programming in C is like lying on a bed of nails. Doable if you are very careful. With C++, they put a sheet over the bed of nails.

galangalalgol 4y ago
I haven't used valgrind in years, more used to asan, but I've been told it can do things asan can't? Edit: to stretch the metaphor, modern c++ is like a thick rubber pad on the bed of nails, but often on the job you are hot bunking and you don't know which c++ your predecessor used to make the bed... Or you are in a hurry and you aren't sure which one you grabbed.
- swinglock 4y ago
  Ideally you use both, as both can find some more obscure issues the other may not. At least in the past. Either in isolation also works well, though Valgrind is really a suite of many tools.
- mtklein 4y ago
  If you're used to ASAN, think of Valgrind like ASAN, TSAN, MSAN, and UBSAN all at once at the same time, and then has other facilities like profiling. In any situation where I have control of how the code is built, I personally prefer to run those various SANs instead of Valgrind, usually three parallel builds: one with -fsanitize=address,integer,undefined, one -fsanitize=thread if more than one thread is involved in the project, and one -fsanitize=memory too if Linux is available. That gets you almost all the benefits of Valgrind faster than Valgrind. But Valgrind is still an exceptionally powerful tool to learn and use. Its chief advantage to me is to be able to work with an unmodified binary. Its chief downside is it can be slow, and occasionally you may run into issues with support for more obscure instructions like vcvtps2ph. MSAN is really the star of the sanitizer world, and is worth spinning up a Linux VM for. It tracks the initialized-ness of all your data and catches any use (really, branch) on anything uninitialized. I like to think of ASAN as "did I get my pointers right?" and MSAN as "did I get everything else right?". If you're not familiar with integer sanitizer, it's like UBSAN except it checks for things that are often mistakes rather than things that are actually undefined. The most common situation I've found is code that's hashing data will often pop up a warning about unsigned integer overflow, which I choose to suppress as finely grained as possible with something like __attribute__((no_sanitize("unsigned-integer-overflow", "unsigned-shift-base"))). That way you can still find unintentional unsigned integer problems (e.g. with size_t).

sfpotter 4y ago

Don't bother with this stuff (or with "modern C") if you're just beginning to learn the language. You don't need it for small programs. No one is going to yell at you if your first effort isn't perfect. And no one is going to yell at you if you read the "wrong" book, or try things out in the "wrong" order. Pick any learning resource and get started now. You'll probably get distracted and move on to something else. Come back to it later or not.

galangalalgol 4y ago
Well C was my second language. I learned it on an amiga 500. But I quickly transitioned to a 386 (yes i know, a downgrade) but my dad put turbo c++ on it and I never wrote much ansi c after that. A bit for odd embedded targets, but mostly c++ my whole career. So I can write old fashioned c, and I don't start new projects in c, but writing c abi shims for c++ libraries or reading modern c is something I do with some frequency. Learning it would be fun maybe as I've never really used c99 or newer for anything.
- sfpotter 4y ago
  My comment is for the OP, not for you. Go nuts learning C tooling and have fun.
kaba0 4y ago
I’m not sure, it does help to even just know about whether your program is faulty, and C doesn’t like telling it you, or in unintuitive ways only.
seba_dos1 4y ago
Do bother with this stuff, it's super helpful and helps you understand your mistakes. Writing C without using sanitizers is like playing a game on hard mode, even for simple programs (especially when you're still learning). You may leave static analyzers for later though, since they're more likely to bother you with unimportant stuff - but not much later.

suprjami 4y ago

You can't rely on one tool, different ones catch different things. No one tool is best. I usually use "-Wall -Wextra -Wpedantic", the GCC static analyser "-fanalyzer", cppcheck, and Clang scan-build. That's good enough for my personal projects. I have a couple of blog posts about this: https://superjamie.github.io/2022/05/24/c-static-analysis-tools https://superjamie.github.io/2022/05/24/c-static-analysis-to... https://superjamie.github.io/2022/11/04/c-static-analysis-tools-part-2 https://superjamie.github.io/2022/11/04/c-static-analysis-to...