How do people get so many seg faults?

Is it that hard for you people to use pointers?

☜☝☞☟

How do people get so many seg faults?
Never really wrote any code, have you?

>>3
I wrote code.

Memory errors are ridiculously easy to get, especially in shit languages like C that have no facility for automatic lifetime of heap memory.

- Off-by-one errors
- Off-by-n errors
- Manual string manipulation
- Manual linked list manipulation
- Non-manual linked list or string manipulation, but you forget to invoke specific functions or macros (e.g., faggot_list_free(&faggot))
- A library function returns a pointer to dynamically allocated memory

We could go on, but here's the lesson. Real, industrial-strength programs do not perform any dynamic allocations during runtime; it simply is unsafe. Small programs that no one really depends on can be written in memory-safe languages. The greatest extent of MMM anyone should do any more, maybe in embedded systems or kernels, is through ref counting or RAII.

I write plenty of c way back and I rarely get seg faults. Pointers are not that hard to get right. You just need to be disciplined. You maybe a mediocre programmer.

>>6
This.

>>6,7
yes. If I get a segfault, the reason is usually very complicated. And if I was using a memory safe language, I'd just get some odd exception instead.

>>6-8
Segmentation faults are the worst memory errors you get. There are still other less harmful but ultimately unsafe memory errors with which your code is probably ridden. High level languages can remove any direct contact with memory. This makes these languages more powerful because you can think about macro-optimizations vis-a-vis your problem instead of 1970s-style memory shuffling.

>>9
Yes, but you get other errors like:
Could not allocate memory. XXXX bytes used. Program crash.
Max execution time exceeded.
Function XXXX did not respond. Timed out. Log >>
defuct, nil, garble, code errors, unidentified failure.
Load on the server is at XXX.XX. Please fix this matter ASAP.
Et cetera.

However I agree with your statement that abstractions are sometimes only needed more times in applications when memory is of little to no concern. That is why I still use scripts like scheme, awk, and ksh93.

The main question that is:
"Should this application require me to know how much memory I need to run it?"

>>6
Rarely
Well, you shouldn't, you douche. Either write memory-safe code by hand always, or use tools which ensure it for you.

Now go scrub another toilet, you mental midget.

I eat lots of fibre, and dump core often and painlessly ☺

>>12
Watch out everybody we have an EXPERT PROGRAMMER over here.

xD xD xD

>>9
I do not test my code, I prove that it is correct.

>>13
Sorry, that was directed toward >>11-sama.

Le sincerest apologies face.

>>13
Yeah, because I don't go around calling other people sissies for not being as sloppy and macho as me.

>>14
They pay your time for that? If most of us tried that, we would be forcibly terminated for taking too long.

Banks and critical infrastructure always use eschew mmm programming environments. There typically isn't a penalty for a few wasted microseconds if it means people won't lose a thousand dollars because you derefed a null pointer.

>>18
Banks don't give a shit about your money unless you have millions of dollars, and if you have millions, you shouldn't care about a thousand.

>>19
maybe in your third world country

>>20
Name one country where it's not like that.
I'll seriously consider moving there if it checks out.

>>18
all financial software is still written in COBOL.
it's horrible ;_;

>>19
If you have billions, cumulative rounding error can easily add up to a few million.

Also, in any non-shit country, failure to comply with basic regulations for things like double entry bookkeeping should result in revocation of the certifications that institutions rely upon to conduct business.