Sounds like you're looking for Solaris, not Linux. In Solaris land, anything goes (most of the time). Bogus memcpy doesn't crash (most of the time). Bogus free doesn't crash (most of the time).
Good for design wins for marketing droids selling to corporates --- "look, your crappy code compiles and runs (most of the time)".
Crap for anyone who actually wants bugs to get fixed.
Posted Mar 28, 2012 8:46 UTC (Wed) by jengelh (subscriber, #33263)
[Link]
>Good for design wins for marketing droids selling to corporates --- "look, your crappy code compiles and runs (most of the time)". Crap for anyone who actually wants bugs to get fixed.
The x86 architecture is just the same (and so are others like IA64).
Changes in glibc development
Posted Mar 28, 2012 10:45 UTC (Wed) by dps (subscriber, #5725)
[Link]
Having used Solaris (SPARC) I know in that land newly allocated memory frequently contains values very different from 0 which can break *buggy* code that allocates an array of pointers on the heap and assumes they are all initially null. This usually just works on Linux.
Solaris has not monopoly on "your bugware just works most of the time". Some bugware dies badly on Solaris but works on Linux and other systems where freshly allocated memory is all 0 most of the time.
What I really don't like in glibc is implementing a pipe2 function returning ENOSYS, if is not implemented, instead of implementing it using pipe(2) and fcntl(2), No doubt someone would call this is a feature but I can't work up enough enthusiasm for it to do so.
Changes in glibc development
Posted Mar 28, 2012 11:42 UTC (Wed) by mpr22 (subscriber, #60784)
[Link]
It's not that returning ENOSYS is a feature, but that pretending to work would be a hidden-race-condition bug.