8 ms·

It’s been such a joy to learn C. There’s a very vocal group that tells you not to write in C because it’s unsafe, immoral and you’ll burn in hell if you do but

It’s been such a joy to learn C. There’s a very vocal group that tells you not to write in C because it’s unsafe, immoral and you’ll burn in hell if you do but the fact is...I would never be able to understand the problem Rust is trying to solve until I’ve recreated the problems in C. By now I’ve hit a good amount of segmentation faults. Would really love to know if there’s a list of all the possible ways to get one oF these in C.

codr7 6y ago
The list would be infinite; and it's a feature, not a bug. You pick up strategies for avoiding problems along the way, to a higher degree than in less flexible languages. Valgrind is your friend, I couldn't imagine writing C without it anymore. Many compilers also ship with verifiers for undefined behavior which has saved me a couple of times.
- flohofwoe 6y ago
  Also: enable all warnings the compiler offers and compile the code with different compilers (clang, gcc, MSVC - they all have different warnings), add copious amounts of assert checks, compile and test with the clang sanitizers enabled (address sanitizer, undefined behaviour sanitizer, thread sanitizer), and run the code through static analyzers (e.g. clang static analyzer and the one in Visual Studio), minimize dynamic allocation and pointer use. With all those combined it's quite hard to hit segmentation faults and memory corruption and the source code will generally become "cleaner" and more robust.
  - manishsharan 6y ago
    This. I wish all C books had more chapters on this.
  - saagarjha 6y ago
    Not all the warnings, as many are not useful. But take -Wall -Wextra and see how that suits you and tweak it if necessary.
    - nwmcsween 6y ago
      I really wish compilers had a -Wstandard and that warned on standard breaking things vs -Wall or -Wextra which has compiler specific junk like -Wparentheses
      - saagarjha 6y ago
        Perhaps -Wpedantic is what you want?
        nwmcsween 6y ago
        No, I basically want a W switch to warn only on potential buggy code (implicit-int, etc)
simias 6y ago
I really like C as well, it's the smallest language I know. From bare metal you can bootstrap a basic C runtime in like 10 lines of ASM (zero the BSS, setup the stack, jump main). I really love Rust these days, but there's no denying that it's a much more complex language. Segfaults are not something C is aware of, it's usually the consequence of triggering an undefined behaviour. But UB being... undefined, all sort of things can and do happen, for instance a buffer overflow can segfault, but it can also overwrite some other variable, or the return address of the function, or do nothing at all. That's really the problem with C. If UB meant segfault, then it wouldn't be so bad because at least you'd immediately know that something went wrong. Instead it's very easy to have small issues go unnoticed for a long time, until your application finally crashes in a seemingly unrelated location or, worse, some clever guy or gal manages to exploit the flaw for fun and profits.
- bogomipz 6y ago
  >"From bare metal you can bootstrap a basic C runtime in like 10 lines of ASM (zero the BSS, setup the stack, jump main)." Might you or someone else have a resource on learning how to do this?
  - kahlonel 6y ago
    I don’t self-promote usually, but I asked some people on Reddit[1] if they would like an educational stream on embedded systems, and a lot of people said yes. I’m doing one on Sunday most probably. Feel free to join in because that’s one of the things I will be talking about. [1] - https://old.reddit.com/r/embedded/comments/ilgyun/would_you_be_interested_in_an_educational_stream/ https://old.reddit.com/r/embedded/comments/ilgyun/would_you_...
    - djeiasbsbo 6y ago
      Hey kahlonel! Just wanted to tell you that I watched your stream and it was really good, I learned a lot. I don't have a twitch account so I couldn't use the chat when you were waiting for someone to show up. So I just wanted to tell you here that everything was great from sound quality to the content you provided! :)
SAI_Peregrinus 6y ago
I'm in both camps at once. I hate C's footguns, I hate the difficulty of doing some things that are simple in other languages (iterators, coroutines, etc). I love C's speed and flexibility. I love the availability of C: any chip I need to program (that isn't an FPGA or such) I can use C. So I push for Rust (and sometimes Zig), because they're better than C in many ways, but they do lose the availability and some of the flexibility.
- skohan 6y ago
  I see them as filling fundamentally different (if occasionally overlapping) use-cases. Rust is a language for high-performance programs which require strong safety guarantees. C is a language to make the computer do what you tell it to. So for instance, if what I need to do is just manipulate memory with the least overhead possible, C is a really good tool for the job where Rust adds unnecessary ceremony. For instance, if I'm just walking arena-allocated memory, the borrow checker does nothing for me. Also I think C plays an important pedagogical role. When writing C you learn a lot about what a computer actually does, whereas with Rust you're working with an abstract system. I think a lot of the reason C gets a bad rap is because it has been used historically in a lot of use-cases where a language with better safety guarantees would have been a better fit, but that alternative didn't exist until maybe quite recently.
  - masklinn 6y ago
    > Also I think C plays an important pedagogical role. When writing C you learn a lot about what a computer actually does, whereas with Rust you're working with an abstract system. That has not been true in decades, if ever. C is very much defined in terms of an abstract machine, and the behaviour of C is not that of the underlying assembly, which itself is an abstraction over the µops which actually tell the hardware how to work.
    - skohan 6y ago
      Yes I mean this will always be true unless you work with raw machine code. The point is the C abstraction is lower level: give me memory, write to memory etc. where with Rust you’re moreso interacting with the compiler in a declarative way
quelsolaar 6y ago
The thing about Segfaults, is that with a good integrated debugger like visual studio, the bugs that produce them are often very easy to diagnose. As a C programmer I would say they are my favorite class of bugs, because they are so easy to fix, and they show them selves so clearly.
- mhh__ 6y ago
  A segfault is really just the CPU and OS working as intended. Not always obvious, but an ill formed access should not fail silently. The issue with C is the silent issues like buffer overruns, i.e. even if you program defensively and with a proper security model you're still opening up to the possibility of leaking your missile codes by accident because you committed bad code
  - quelsolaar 6y ago
    I agree. Silent issues are the problem that needs addressing. Personally I think bugs should be addressed, with better debug modes and tools. Take this example: int i, array[10]; for(i = 0; i < 11; i++) array[i] = 0; A clear bug, right? You could write this type of bug in any language. Many languages would stop you from writing outside the array. In C its undefined behavior. Undefined behavior means that the compiler doesn't have to do anything, therefor it doesn't have to at run time test if the code is correct. It can assume that the programmer knows what they are doing. Thats why C has great performance, but also why bugs can be silent and hard to find. But, It doesn't meant that the compiler has to ignore the issue. Its undefined behavior, so the compiler is free to do all the checks that a language that doesn't let you write outside an array do. Sure, then C will become just as slow as other languages, but you can now find and remove the silent bug. This is why I think that debug mode, should be very different from release mode. The two compilers have entirely different design goals. Some compilers are starting to do this. Visual studio will for instance break if you access a lot of uninitialized values in debug mode, something that it will ignore in release mode. There are loads of things that could be done to improve debugging that doesn't require the language to change or to slow down the release runtime.
- bvinc 6y ago
rhacker 6y ago
> There’s a very vocal group that tells you not to write in C because it’s unsafe I get the reasoning to learn it. Just after you do learn it, stop and use something else. Unless you absolutely have to. I don't think anyone has attempted to compute the amount of money spent on buffer overflow hacks. But I'm guessing it's in the 10s to 100s of billions of dollars if you count all the viruses that took advantage of it in the past in Apache web server or Windows NT's NTFS (or sharing etc...) codebases. And that applies to C++ too. And hey, I know that sounds extreme - but there really are situations of "unless you absolutely have to" but I wouldn't expect anyone to write a brand new queuing system or database in C or C++ anymore given the alternative languages available.
- non-entity 6y ago
  For C I mostly agree, but from what I understand there's still a ton of new C++ being written and even replacing "legacy" alternative languages even if they provide advantages.
  - stjohnswarts 6y ago
    Modern c++ can get you 95% of what rust offers. It's just that the syntax is hideous, especially templates
- nikki93 6y ago
  If you're writing a web server or an OS, yes you need to be careful and it might be easier to be careful in other languages (allegedly). But if you're making a game or playing around in WASM, it's fine and you're not going to cost anyone billions of dollars.
- einpoklum 6y ago
  > but I wouldn't expect anyone to write a brand new queuing system or database in C or C++ anymore given the alternative languages available. Then you expect wrong, at least about Database Management Systems. New performant ones are often (/ mostly?) written in C++. At least that's what it's like for analytical DBMSes. Some examples: * HyperDB: https://www.hyper-db.de/ https://www.hyper-db.de/ * DuckDB: https://duckdb.org/ https://duckdb.org/ * Vectorwise/Actian Vector: https://www.actian.com/analytic-database/vector-analytic-database/ https://www.actian.com/analytic-database/vector-analytic-dat... And you might also be surprised that many problems originally carried over from C to C++, like dereferencing nulls and memory leaks can be done away with - not by being super-careful, but by sticking to newer language facilities and using some static analysis. Other, like buffer overruns, are easier to avoid with things like spans and ranged-for loops.
einpoklum 6y ago
> By now I’ve hit a good amount of segmentation faults. I'm not sure learning by repeating the failures of the past is a very scalable practice... :-)
xenadu02 6y ago
The biggest problem C has is the standards committee. They appear to have given up on making any significant improvements to the language. C could have an optional bounds checking mode. It is possible to design such a feature in a way that allows progressive adoption without breaking compatibility with existing libraries. C could also choose to move some forms of Undefined Behavior to implementation-defined or even defined. Many of the current standards committee members are active impediments to progress. We'd all be better off if we hit the reset button on that. Just look at what the C++ group has been doing by comparison...
bumblebritches5 6y ago
I've lately been getting segmentation faults for not casting math with diff signs, so pretty much anything can cause it.

codr7 6y ago

The list would be infinite; and it's a feature, not a bug. You pick up strategies for avoiding problems along the way, to a higher degree than in less flexible languages. Valgrind is your friend, I couldn't imagine writing C without it anymore. Many compilers also ship with verifiers for undefined behavior which has saved me a couple of times.

flohofwoe 6y ago
Also: enable all warnings the compiler offers and compile the code with different compilers (clang, gcc, MSVC - they all have different warnings), add copious amounts of assert checks, compile and test with the clang sanitizers enabled (address sanitizer, undefined behaviour sanitizer, thread sanitizer), and run the code through static analyzers (e.g. clang static analyzer and the one in Visual Studio), minimize dynamic allocation and pointer use. With all those combined it's quite hard to hit segmentation faults and memory corruption and the source code will generally become "cleaner" and more robust.
- manishsharan 6y ago
  This. I wish all C books had more chapters on this.
- saagarjha 6y ago
  Not all the warnings, as many are not useful. But take -Wall -Wextra and see how that suits you and tweak it if necessary.
  - nwmcsween 6y ago
    I really wish compilers had a -Wstandard and that warned on standard breaking things vs -Wall or -Wextra which has compiler specific junk like -Wparentheses
    - saagarjha 6y ago
      Perhaps -Wpedantic is what you want?
      - nwmcsween 6y ago
        No, I basically want a W switch to warn only on potential buggy code (implicit-int, etc)

simias 6y ago

I really like C as well, it's the smallest language I know. From bare metal you can bootstrap a basic C runtime in like 10 lines of ASM (zero the BSS, setup the stack, jump main). I really love Rust these days, but there's no denying that it's a much more complex language. Segfaults are not something C is aware of, it's usually the consequence of triggering an undefined behaviour. But UB being... undefined, all sort of things can and do happen, for instance a buffer overflow can segfault, but it can also overwrite some other variable, or the return address of the function, or do nothing at all. That's really the problem with C. If UB meant segfault, then it wouldn't be so bad because at least you'd immediately know that something went wrong. Instead it's very easy to have small issues go unnoticed for a long time, until your application finally crashes in a seemingly unrelated location or, worse, some clever guy or gal manages to exploit the flaw for fun and profits.

bogomipz 6y ago
>"From bare metal you can bootstrap a basic C runtime in like 10 lines of ASM (zero the BSS, setup the stack, jump main)." Might you or someone else have a resource on learning how to do this?
- kahlonel 6y ago
  I don’t self-promote usually, but I asked some people on Reddit[1] if they would like an educational stream on embedded systems, and a lot of people said yes. I’m doing one on Sunday most probably. Feel free to join in because that’s one of the things I will be talking about. [1] - https://old.reddit.com/r/embedded/comments/ilgyun/would_you_be_interested_in_an_educational_stream/ https://old.reddit.com/r/embedded/comments/ilgyun/would_you_...
  - djeiasbsbo 6y ago
    Hey kahlonel! Just wanted to tell you that I watched your stream and it was really good, I learned a lot. I don't have a twitch account so I couldn't use the chat when you were waiting for someone to show up. So I just wanted to tell you here that everything was great from sound quality to the content you provided! :)

SAI_Peregrinus 6y ago

I'm in both camps at once. I hate C's footguns, I hate the difficulty of doing some things that are simple in other languages (iterators, coroutines, etc). I love C's speed and flexibility. I love the availability of C: any chip I need to program (that isn't an FPGA or such) I can use C. So I push for Rust (and sometimes Zig), because they're better than C in many ways, but they do lose the availability and some of the flexibility.

skohan 6y ago
I see them as filling fundamentally different (if occasionally overlapping) use-cases. Rust is a language for high-performance programs which require strong safety guarantees. C is a language to make the computer do what you tell it to. So for instance, if what I need to do is just manipulate memory with the least overhead possible, C is a really good tool for the job where Rust adds unnecessary ceremony. For instance, if I'm just walking arena-allocated memory, the borrow checker does nothing for me. Also I think C plays an important pedagogical role. When writing C you learn a lot about what a computer actually does, whereas with Rust you're working with an abstract system. I think a lot of the reason C gets a bad rap is because it has been used historically in a lot of use-cases where a language with better safety guarantees would have been a better fit, but that alternative didn't exist until maybe quite recently.
- masklinn 6y ago
  > Also I think C plays an important pedagogical role. When writing C you learn a lot about what a computer actually does, whereas with Rust you're working with an abstract system. That has not been true in decades, if ever. C is very much defined in terms of an abstract machine, and the behaviour of C is not that of the underlying assembly, which itself is an abstraction over the µops which actually tell the hardware how to work.
  - skohan 6y ago
    Yes I mean this will always be true unless you work with raw machine code. The point is the C abstraction is lower level: give me memory, write to memory etc. where with Rust you’re moreso interacting with the compiler in a declarative way

quelsolaar 6y ago

The thing about Segfaults, is that with a good integrated debugger like visual studio, the bugs that produce them are often very easy to diagnose. As a C programmer I would say they are my favorite class of bugs, because they are so easy to fix, and they show them selves so clearly.

mhh__ 6y ago
A segfault is really just the CPU and OS working as intended. Not always obvious, but an ill formed access should not fail silently. The issue with C is the silent issues like buffer overruns, i.e. even if you program defensively and with a proper security model you're still opening up to the possibility of leaking your missile codes by accident because you committed bad code
- quelsolaar 6y ago
  I agree. Silent issues are the problem that needs addressing. Personally I think bugs should be addressed, with better debug modes and tools. Take this example: int i, array[10]; for(i = 0; i < 11; i++) array[i] = 0; A clear bug, right? You could write this type of bug in any language. Many languages would stop you from writing outside the array. In C its undefined behavior. Undefined behavior means that the compiler doesn't have to do anything, therefor it doesn't have to at run time test if the code is correct. It can assume that the programmer knows what they are doing. Thats why C has great performance, but also why bugs can be silent and hard to find. But, It doesn't meant that the compiler has to ignore the issue. Its undefined behavior, so the compiler is free to do all the checks that a language that doesn't let you write outside an array do. Sure, then C will become just as slow as other languages, but you can now find and remove the silent bug. This is why I think that debug mode, should be very different from release mode. The two compilers have entirely different design goals. Some compilers are starting to do this. Visual studio will for instance break if you access a lot of uninitialized values in debug mode, something that it will ignore in release mode. There are loads of things that could be done to improve debugging that doesn't require the language to change or to slow down the release runtime.
bvinc 6y ago

rhacker 6y ago

> There’s a very vocal group that tells you not to write in C because it’s unsafe I get the reasoning to learn it. Just after you do learn it, stop and use something else. Unless you absolutely have to. I don't think anyone has attempted to compute the amount of money spent on buffer overflow hacks. But I'm guessing it's in the 10s to 100s of billions of dollars if you count all the viruses that took advantage of it in the past in Apache web server or Windows NT's NTFS (or sharing etc...) codebases. And that applies to C++ too. And hey, I know that sounds extreme - but there really are situations of "unless you absolutely have to" but I wouldn't expect anyone to write a brand new queuing system or database in C or C++ anymore given the alternative languages available.

non-entity 6y ago
For C I mostly agree, but from what I understand there's still a ton of new C++ being written and even replacing "legacy" alternative languages even if they provide advantages.
- stjohnswarts 6y ago
  Modern c++ can get you 95% of what rust offers. It's just that the syntax is hideous, especially templates
nikki93 6y ago
If you're writing a web server or an OS, yes you need to be careful and it might be easier to be careful in other languages (allegedly). But if you're making a game or playing around in WASM, it's fine and you're not going to cost anyone billions of dollars.
einpoklum 6y ago
> but I wouldn't expect anyone to write a brand new queuing system or database in C or C++ anymore given the alternative languages available. Then you expect wrong, at least about Database Management Systems. New performant ones are often (/ mostly?) written in C++. At least that's what it's like for analytical DBMSes. Some examples: * HyperDB: https://www.hyper-db.de/ https://www.hyper-db.de/ * DuckDB: https://duckdb.org/ https://duckdb.org/ * Vectorwise/Actian Vector: https://www.actian.com/analytic-database/vector-analytic-database/ https://www.actian.com/analytic-database/vector-analytic-dat... And you might also be surprised that many problems originally carried over from C to C++, like dereferencing nulls and memory leaks can be done away with - not by being super-careful, but by sticking to newer language facilities and using some static analysis. Other, like buffer overruns, are easier to avoid with things like spans and ranged-for loops.

einpoklum 6y ago

> By now I’ve hit a good amount of segmentation faults. I'm not sure learning by repeating the failures of the past is a very scalable practice... :-)

xenadu02 6y ago

The biggest problem C has is the standards committee. They appear to have given up on making any significant improvements to the language. C could have an optional bounds checking mode. It is possible to design such a feature in a way that allows progressive adoption without breaking compatibility with existing libraries. C could also choose to move some forms of Undefined Behavior to implementation-defined or even defined. Many of the current standards committee members are active impediments to progress. We'd all be better off if we hit the reset button on that. Just look at what the C++ group has been doing by comparison...

bumblebritches5 6y ago

I've lately been getting segmentation faults for not casting math with diff signs, so pretty much anything can cause it.