6 ms·

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 progra

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
> As a C programmer I would say they are my favorite class of bugs, because they are so easy to fix, I know what you're trying to say, because at least 95% of segmentation faults are easy to fix, but I take issue with this. The hardest bug that I've ever fixed was a segmentation fault! You've obviously never experienced random crashes where the best idea anyone has is to bisect code changes in production and see when the crashes stop. And you've obviously never experienced random crashes on customer machines where you've tested the crashing function for weeks, poured over crash dumps and ran the exact same function with the exact same data and could never reproduce it.
- saagarjha 6y ago
  I think you're leaving out the option that the person you're replying to has seen even worse bugs because they have better ideas of how to deal with random crashes than bisecting code changes. For example, with the details you provided (of which there isn't much) I would suspect a thread safety issue.
  - quelsolaar 6y ago
    Thank you! I find that the worst bugs are usually the ones involving the logic of the algorithm, and the language has nothing to do with the bug itself. This is why I think that a language that is very explicit, and without side effects and therefor easy to step though using a debugger is desirable. Buffer over runs, can be trickier, but I have plenty of tooling to find the issues. Thread safety issues are what nightmares are made of.
deleted 6y ago
[deleted]

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

> As a C programmer I would say they are my favorite class of bugs, because they are so easy to fix, I know what you're trying to say, because at least 95% of segmentation faults are easy to fix, but I take issue with this. The hardest bug that I've ever fixed was a segmentation fault! You've obviously never experienced random crashes where the best idea anyone has is to bisect code changes in production and see when the crashes stop. And you've obviously never experienced random crashes on customer machines where you've tested the crashing function for weeks, poured over crash dumps and ran the exact same function with the exact same data and could never reproduce it.

saagarjha 6y ago
I think you're leaving out the option that the person you're replying to has seen even worse bugs because they have better ideas of how to deal with random crashes than bisecting code changes. For example, with the details you provided (of which there isn't much) I would suspect a thread safety issue.
- quelsolaar 6y ago
  Thank you! I find that the worst bugs are usually the ones involving the logic of the algorithm, and the language has nothing to do with the bug itself. This is why I think that a language that is very explicit, and without side effects and therefor easy to step though using a debugger is desirable. Buffer over runs, can be trickier, but I have plenty of tooling to find the issues. Thread safety issues are what nightmares are made of.

deleted 6y ago

[deleted]