| ▲ | Game Boy Advance Dev: Logging to the Console(mattgreer.dev) | |||||||
| 30 points by jandeboevrie 12 hours ago | 3 comments | ||||||||
| ▲ | Crisco 6 hours ago | parent | next [-] | |||||||
I recently got into GBA development and was planning on figuring out how to do this exact thing today, so I’m happy to have found this article. Anecdotally I’ve found that GBA and embedded development is very fun, especially since I’ve set the rule for myself to never use LLM generated code. I don’t really have the ability to not interact with LLMs at work, so being able to return to how things used to be and feel the satisfaction of building a project from scratch has enhanced my interest and excitement for personal projects. | ||||||||
| ||||||||
| ▲ | scraft 9 hours ago | parent | prev [-] | |||||||
Small defensive suggestion: I’d usually define both the enabled and disabled versions as statement-like macros:
For the exact usage shown here, "mgbalog(...);" will mostly work with the empty replacement-list version, since it just leaves a bare ";". So this is not a guaranteed bug.The reason I prefer the "do { } while (0)" form is that it keeps the macro structurally equivalent to a single statement in both debug and release builds. With the empty disabled macro, this:
becomes:
That is valid C, but it can trigger empty-body / suspicious-semicolon warnings, for example GCC’s "-Wempty-body", which matters if the project builds with "-Wextra" or warnings-as-errors.It also means the enabled case is already set up correctly if the macro later grows beyond a single function call. For example, if you later add another statement to the macro:
then the expansion breaks because the "else" no longer attaches to the intended "if".So in this specific case the empty macro is probably fine for ordinary "mgbalog(...);" calls, but wrapping both versions in "do { } while (0)" is the more conventional and future-proof C macro shape. | ||||||||