Live data from Hacker News

This should never happen

github.com

211–214 of 214 posts

Re: This should never happen

#211
post #187

Earlier quoted context omitted.

Not quite for memory _corruption_ but back when I was writing API code in C, I would place 'sentinels' at each end of my structs. struct somestruct { int s1; int data; char * moreData; int s2; } When the caller of the API needed to call my code, it had to first call a function to get an instance of the struct. This constructor like code would allocate the memory for the struct, and then set s1 and s2 to 0xDEADBEEF; T…

This one is compelling. However this might not have caught the error condition described upthread. That condition might have overwritten data or moreData without touching s1 or s2 . Otherwise, great!

Reminds me of a stack canarys, stuff you put on the feet off a stack and check with the scheduler.

Also to all those ready to do a checksum on a struct, rememember that structs are plattform dependant (padding bytes).

Re: This should never happen

#214

Earlier quoted context omitted.

Not quite for memory _corruption_ but back when I was writing API code in C, I would place 'sentinels' at each end of my structs. struct somestruct { int s1; int data; char * moreData; int s2; } When the caller of the API needed to call my code, it had to first call a function to get an instance of the struct. This constructor like code would allocate the memory for the struct, and then set s1 and s2 to 0xDEADBEEF; T…

This reminds me of something a friend of mine did once. He had a structure that was getting overwritten with garbage due to an overrun somewhere else in the code. Rather than debugging and trying to find out what was doing it he just put "char temp[1000];" at the top of the struct to "absorb the damage". I believe it's still running like that in production to this day.

This is kind of an extension of the "throw more hardware at poor performance"... but its throwing more bytes at bad code ;)
Post reply on HN