Well, yes C doesn't officially have a data segment, and it only sort of has a stack. I only know of one C implementation that doesn't (C on LISPM). More importantly because the stack, data segments, type widths, and lots of other "assembler like" things bleed through the abstractions when you look at either performance, or more importantly, bugs.
If you know how C's stack works on your CPU finding stack smashing bugs will be far simpler. If you know how your libc's malloc works finding "use after free", or whatever.
Using this sort of knowledge for "good" will help you debug. A whole lot.
Using it for evil (I know I can use memory after free as long as I don't malloc again, I know mallocs are rounded up to 16 bytes, I know the stack grows down, I know...) will create awesome bugs when somebody tries to use your code on a new CPU, new OS, new C compiler, or with a new libc. If there is any justice in the world the "somebody" will be you, but sadly it isn't always.
I'm on the fence about how much you can use it to optimize (speed or storage size) for without being good or evil :-)
by Stripes — Dec 31
If you know how C's stack works on your CPU finding stack smashing bugs will be far simpler. If you know how your libc's malloc works finding "use after free", or whatever.
Using this sort of knowledge for "good" will help you debug. A whole lot.
Using it for evil (I know I can use memory after free as long as I don't malloc again, I know mallocs are rounded up to 16 bytes, I know the stack grows down, I know...) will create awesome bugs when somebody tries to use your code on a new CPU, new OS, new C compiler, or with a new libc. If there is any justice in the world the "somebody" will be you, but sadly it isn't always.
I'm on the fence about how much you can use it to optimize (speed or storage size) for without being good or evil :-)