Well, what most of us do... manage to reproduce it by chance one out of twenty attempts and then remove any evidence that you managed to trigger it and mark the ticket "unable to reproduce". Bury the ticket by removing any good tags or keywords and hope it's at least three months until anyone else reports the error so you can repeat the dance.
Clang won’t tell you if you’re missing a return statement, even with all warnings on and will just let it crash during runtime. Static analysis won’t save you from all stupid mistakes.
Static analysis won't save you from all of them, but they will definitely save you from the great majority of the ones ProgrammerHumor seems to get worked up about.
I still see people sharing ancient memes about pouring over code for hours looking for mismatched curly braces, missing semicolons, and greek question marks. These and the bulk of minor syntax problems like them should all be complete non-issues with modern tooling.
As an Emacs user, I always have to deal with coworkers false imaginings that I don't have modern intelligent code-aware features, who assume I'm some sort of Luddite who's rejecting "modern" tooling.
I have of course worked with people who use VS Code in a sophisticated way, but most often I'm astonished when I work alongside them over their shoulder and find that they just don't use most of these features or know how. I've had colleagues work for months on end without managing to turn on various (Python) checkers, trying to PR code full of errors and fixing them based on CI run errors, and even after me pointing out there are plugins they can get all this, weeks/months later I find they still haven't worked it out.
Many devs I've worked with didn't know, after jump to a definition, you can jump back to where you jumped from. It's painful watching them jump to definition and then manually search their tabs to try to remember where they came from.
I had similar experiences with vocal vim fanboys who loved to make fun of Emacs, and then I watched their workflows and they were painful and I realized I knew more about sophisticated vim usage than they did.
It's on the company computer, but I have a backup from earlier today that seems to have the same code.
bool load_metadata() {
uint8_t marker_field = EEPROM.read(0);
// Write to ROM if marker has not been set
if (marker_field != MARKER) {
metadata = {
0,
};
EEPROM.put(1, metadata);
EEPROM.update(0, MARKER);
}
else {
EEPROM.get(1, metadata);
}
}
I have to admit, my experience with C++ is rather limited, last Monday was the first time in my life that I used a C++ compiler. I had some issues getting it to work with Visual Studio, so I ended up using VS Code WSL with clang 😅.
Does this compile with -Wall -Werror? (might not be an option if your dependencies’ headers contain warnings)
Looks like it may be embedded code for a SoC or similar. The only things I can think of is that the tool chain you’re using maybe non-standard… or you’re invoking the dreaded Undefined Behaviour somewhere :(
I didn’t use -Werror but no warning about it showed up either. The project uses a semi-custom toolchain for a microcontroller, but I’m not using it to compile this code. I have another file with an entrypoint which tests some classes to be used by the microcontroller. The EEPROM in the code example is actually a macro for a class I’ve written that emulates the EEPROM library by writing and reading to a file on disk.
It’s a bit of a mess but this dual toolchain setup seemed easier than emulating the board and peripherals in it’s entirety. I might have to retry that though using Wokwi.