Memzoom – view/monitor the raw memory of processes/files in your UTF-8 terminal

> Debuggers and profilers already exist for the developers of applications to know these things.

One big difference between an intermediate and an expert programmer is that an expert develops their intuition for how the program they write will compile and run. Can you guess correctly how fast, or how slow each function will be? Or what the optimizer will do a good or a bad job at optimizing? Can you tell before you've written your code when avoiding allocations is going to speed things up, and when it won't matter?

Debuggers and profilers honestly aren't very good at giving you a "zoomed out" view of whats going on in your program. Each tool shows you a specific aspect of your program, and hides everything else. For profilers, thats usually what the CPU spends its time on. For debuggers, the execution path of a single function. Godbolt shows how the optimizer works. And so on.

But from my perspective, having more tools which show different aspects of my code is almost always a win. I never know ahead of time which perspective will let me double my program's performance, or halve memory usage. Writing code is easy. Understanding code is much more complex.

So yeah, from a software development point of view I think this is neat! I want to give it a try on some of my programs because I expect to see my mental model animated back at me, and I anticipate being surprised. This looks cool!

if you mean the straight-forward nature of the code, I agree.

I think we over-complicate code today because we are promised ease of maintenance, or high-level declaration, or something else, and I don't think those promises have ever come true, except in very small textbook-type examples.

That's a good instinct to have. 99% of the time we're writing something like an object library that's part of a much larger program. To use global variables in such code would impose difficulties on the application as a whole, with regard to things like threading, pollution of the linker symbol table, etc. But when you're writing small main.c programs like this one which don't use threads, globals can be a real advantage. In gdb, you can easy inspect their values. You can look at the linker output manifest listing to see how they're being arranged in your binary. If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. It's just not one that scales to large monolithic programs that most companies prefer to create. So over the years a cultural aversion to it was developed in many style guides.

The "rule" that I've sort of figured out from reading old C code is that global state in the file that contains main() is ok.

For a well written code that is less than 1000 lines in a single file using very few abstractions, that number of global variables is not a problem.

This is good information. On one of my other blog posts, I talk about what different types of memory look like under this viewer. https://justine.lol/sizetricks/#look It should give you the basic idea of how to interpret what you see under this intuitive display. It also goes more in depth into how size optimization tricks like struct alignment can be done.

That did the trick, thank you.

This. I'd be nice to have a list of strings to monitor (ex: half of the ssh private key) and warn when they are found somewhere, to detect data exfiltration.

Surely whatever RE tool you're using already has a memory viewer built in.