| I was also slightly disappointed not to find a discussion of <code smells>, but the post is interesting, and we can still discuss code smells here. The post author (Michal Necasek) states, about the WIN87EM.DLL code: > It bears all the hallmarks of code that was written, rewritten, rewritten again, hacked, tweaked, modified, and eventually beaten into submission even if the author(s) had no real idea why it finally worked. From what I gather, here are those hallmarks: - Looping a no-op action, presumably to slow things down. - Unnecessarily performing actions multiple times. This happens for three things: (a) writing a zero to an I/O port to clear something; (b) executing an instruction to clear exceptions; and (c) repeating the aforementioned no-op loop at different points. - Saving a status in a separate location, only to reinstate it to its original location after clearing things out. - Communicating procedure state (an EOI, “end of interrupt”) to one entity (the master interrupt controller) but not another (the controller’s slave). Furthermore, this “end” signal was sent near the beginning of the procedure. (This final point is my own observation and not explicitly called out by the author. Perhaps it’s common and not “smelly” for interrupt handlers to do this up front.) I’ve tried to reframe the technical terms as actions and signals in a way that could be recognizable to devs of higher-level systems. My familiarity with OS-level systems is minimal so my interpretations could be a little wrong. But despite my lack of knowledge, and with the author’s help, it does seem clear that there were serious timing and state related bugs here. And as a dev at other levels of the stack, I can relate: it’s very hard to reason about async global state! And this code’s responsibility was handling math errors, not timing errors. It is - or, perhaps, should be - the responsibility of the OS to orchestrate these things appropriately so that math libraries can focus on math stuff. So my takeaways, for “code smells of desperation”, would be: - There are violations of module responsibility. - There are modifications of process timing with no discernible reason. - There are modifications of status/environment/state with no discernible reason. - And finally, other experts (in this case, the post author) can’t make sense of the code. |