Open dirkx opened 2 years ago
What is the problem? I assume .ino.hex is a .hex file, and the message you show (an informative message, not an error message) looks fine to me.
Just to suppress this message - it is indeed a false positive and warning.
But unfortunately - becoming a common one - and playing havoc with automated processing tooling that triggers on this message.
The proposed fix simply makes the check a bit more strict/contemporary (i.e. post the 8.3 dos era).
I don't see anything wrong with the current code. I don't even see how the "fix" would change anything (apart from making stm8flash fail to compile where rindex is not available). Both strrchr and rindex return a pointer to the last dot in the filename.
If the message is a problem for your workflow, maybe we should have a --verbose option, and only emit it then?
you probably have a good reason so enlighten me. Why is your automation tool reading stderr/stdout? stm8flash gives return codes to indicate success or failure. also I agree with spth, the "fix" doesn't seem to change any behaviour. hiding the warning behind --verbose seems fair, since it is after all only a warning
In unix land - indeed no issue at all - there things trigger on exit(3) from stdlib. The issue is tools like Arduino, PIO, naive git-pipelines and others; which seem to use stdout (not even stderr) to 'find' warnings and errors.
But agreed - simply moving it under a verbose (or level 2 verbose) flag absolutely solves this.
Increasingly we have flash filenames like foo.ino.hex (Ardino) or foo.s8.hex or foo.signed.hex (or pkcs8/p8) for signed HEXes.
This confuses stm8flash - and gives a
Due to its file extension (or lack thereof), "/var/folders/dn/nfs_l_hs0cs0g.......2/07_all.ino.hex" is considered as INTEL HEX format!
error message.