The author is very clear about what's important: > A central principal of C-Kermit development is to keep all new releases backwards compatible, not only in it

The author is very clear about what's important: > A central principal of C-Kermit development is to keep all new releases backwards compatible, not only in its command repertoire but also in its compilability on every platform where it could be compiled before no matter how dated its C compiler might be. This includes #if/#endif used to maintain support for K&R C, most recently updated last December to support the default compiler mode on HP/UX. Do you hold yourself to this high standard? I certainly see it as admirable but Quixotic. (Last year I dropped Python 2 support in my package, which had been 2/3 compatible.) As to "stricter defaults", the author clearly disagrees with clang authors that dangling-else warnings should be part of the "stricter defaults" at all. That doesn't mean the author doesn't care about code quality. Kermit has worked for 40 years on 'nine different operating system families and at least 190 different Unix varieties'. That's its own indication of quality. As I read it, the author is actively working to prevent/reduce compiler warnings. But as the compilers become more finicky he's having to "fix" code that's following the C specification and has been working for (say) 30+ years. Is appeasing the compiler really improving code quality? Bear in mind too that every change to the code might introduce something which causes the code to not compile on an old system.