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 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.
boolload_metadata(){
uint8_t marker_field = EEPROM.read(0);
// Write to ROM if marker has not been setif (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.
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 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.
deleted by creator
clangdshould have warned you about this before you even considered compiling.Thanks, I’ve tried it and it works a lot better than the built in intelli-sense.
Is this C++? Have you got some code examples?
I’ve been writing C++ for 20+ years and the last compiler I encountered this with was Borland’s. In the late 90s.
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
-Werrorbut 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.