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.
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.