4 ms·

Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?

p0nce 4y ago
This is quite rare in C++ since C++11.
mbrodersen 4y ago
I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.
farseer 4y ago
Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.
ncmncm 4y ago
It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)
papito 4y ago
Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!
- jcelerier 4y ago
  > Stop writing your own DSLs! 100% disagree. Writing custom DSLs is how you get the best programs.
yakubin 4y ago
The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.
- kaba0 4y ago
  Depends, if it happens in prod, you are **
  - yakubin 4y ago
    If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.
    - kaba0 4y ago
      Fair enough.
- klodolph 4y ago
  Segfault is only best-case scenario if it happens at the location with the bug. It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.
  - yakubin 4y ago
    Agreed.
    - Kon-Peki 4y ago
      My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities. I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?

This is quite rare in C++ since C++11.

I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.

farseer 4y ago

Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.

ncmncm 4y ago

It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)

papito 4y ago

Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!

jcelerier 4y ago
> Stop writing your own DSLs! 100% disagree. Writing custom DSLs is how you get the best programs.

yakubin 4y ago

The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.

kaba0 4y ago
Depends, if it happens in prod, you are **
- yakubin 4y ago
  If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.
  - kaba0 4y ago
    Fair enough.
klodolph 4y ago
Segfault is only best-case scenario if it happens at the location with the bug. It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.
- yakubin 4y ago
  Agreed.
  - Kon-Peki 4y ago
    My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities. I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?