# Is a memory leak and a lack of concurrent safety enough to make code unreviewable?

There is this question which has one close vote and three down-votes. The only comments are

1. The code is broken because it doesn't deallocate memory (and because it uses a global variable although that observation is incorrect).
2. The code won't work in a concurrent context.

Looking at the policy expounded in Are code snippets with known memory leaks broken?, this should not be considered broken.

I can't even find a policy on concurrency, although it seems like it should be obvious that it should not be considered broken unless the code is intended for concurrent use. Not thread safe is a reviewable observation, not a bug in my opinion.

There is one thing about the question that is in fact off-topic:

Also I've not used free() all that much as I was never very good with it for some reason. I'd love advice on where to use free() and how.

That's asking for code to be written. But no one has explained that that is problematic to the asker. So instead of fixing that, the asker tried to fix the things from the comments. But now the question really does have bugs, because one of the fixes is incorrect (it checks the wrong value after a malloc).

It's unclear to me how to fix this question now. Roll back the edit that introduced the bug and edit out the off-topic line?

I flagged the "comments" that are really answers. But I can't flag the down-votes.

I could answer the question. But which version? The original? Or the revised, more broken version?

• I don't see a comment about concurrency on it, but I'm assuming it has been removed. Feb 10, 2020 at 11:23
• "I didn't really understand why concurrency was brought up as this code doesn't target concurrency at all". Yeah closing because it's not got concurrency seems like a bad joke. Are we going to close questions that work with ASCII but they don't always work with the new standard - UTF...
– Peilonrayz Mod
Feb 10, 2020 at 11:57
• @SimonForsberg don't see a comment about concurrency I commented thus as an argument against a non-local "overflow", and removed the comment when the source no longer showed such. (I think it obvious that non-reentrant does not imply broken, let alone make a question not useful.) Feb 10, 2020 at 12:32
• I saw comments about it being incomplete, and they were correct at that point in time -- the code was missing a few important functions. It's been edited since so I'll remove my downvote. Feb 11, 2020 at 12:30

Indeed neither memory issues or concurrency should be a reason for closing a questions. Seems like someone is a bit trigger-happy on the close vote. (And possibly down-vote trigger-happy as well).

Also I've not used free() all that much as I was never very good with it for some reason. I'd love advice on where to use free() and how.

It could be considered as asking for code to be written, but doesn't necessarily have to be. It's asking for advice, and an answer that explains free() in general might be good enough.

Personally I wouldn't pay too much attention to this statement, because it would be quite easy to rephrase it to make it more on-topic.

It's unclear to me how to fix this question now. Roll back the edit that introduced the bug and edit out the off-topic line?

The "off-topic line" doesn't necessarily have to be edited out in my opinion, for the reasons mentioned above. But if necessary, I think removing "I'd love advice on where to use free() and how." would be enough

I could answer the question. But which version? The original? Or the revised, more broken version?

Feel free to answer any version of the question that you choose, preferably one that is not "super-obvious off-topic" but in my opinion, neither version now is "obvious" off-topic. My recommendation is if you answer the question but in case of rollback or change, it would make it easier if you're willing to edit your answer to reflect the resulting question. Rolling back the edit seem like a better choice, as the arguments for making the edit in the first place are invalid.