15 Feb
2018
15 Feb
'18
4:07 a.m.
"worked for him" is an allowed rule under the "I don't know why it
worked but it did" hacking code, for a deadline.
somebody in product land has a sign saying 'the best is the enemy of
the good enough" which people in tech support want to ritually burn
because all he did is shift cost out of his bucket into somebody
elses, but thats also allowed under the "not my problem" rule.
I (and I am self-confessed as the worlds least competent programmer)
frequently found the delay between where corruption in malloc is
applied and where its detected sufficiently confusing that I would
have been tempted to follow this well trodden "remove the free()"
path.
-G
On Thu, Feb 15, 2018 at 12:28 AM, Ron Natalie <ron(a)ronnatalie.com> wrote:
already 20 years ago I met a guy (masters degree,
university) who never freed dynamically allocated memory. He told me he is
'instantiating a object', but had no idea what an heap is, and what dynamically
allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood
the difference between an array and pointer, and apparently couldn't be bothered to
learn.
After string him along for three months, I was on my way into his office to fire him when
I found out he had quit, but not before he checked a bunch of drek into our source code
control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I
found this small utility function that predated the source code control system leaking.
This, I thought was odd, as it had been there FOREVER and was well tested. I brought up
the source code system and checked it anyhow and found the afore mentioned programmer had
checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and
often this causes a core dump in a subsequent malloc/free call. Apparently this was the
place it struck him, so he just deleted the free call there.