Extension detection is a bit naive

[dirkx]

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.

[spth]

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.

[dirkx]

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

[spth]

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.

[spth]

If the message is a problem for your workflow, maybe we should have a --verbose option, and only emit it then?

[schneidersoft]

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

[dirkx]

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.