Extension detection is a bit naive #150
Comments
…ino.hex; or foo.sig.hex which are increasingly common. (Fixes vdudouyt#150)
|
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.
The text was updated successfully, but these errors were encountered: