C-Kermit Update History (since 8.0)(kermitproject.org)
kermitproject.org
C-Kermit Update History (since 8.0)
https://www.kermitproject.org/ckupdates.html
4 comments
There's some nice complaints about the difficulties of doing (really) long-term software development.
"Unix and C badly need a "stability layer" to keep programs working over the long term."
""Dangling else" is (or was) perfectly legal when used correctly; the C language was originally designed for use by people who knew what they were doing .... It makes no sense to keep changing this or any other programming language out from under all the millions of programs that have already been written in it."
"In my view it is a CRIME to change an API for any reason when unknown numbers of programs depend on it, and unknown numbers of people depend on those programs."
"What I don't understand is how large segments of the world's economy can be based on software written in a language that keeps changing out from underneath it."
"Unix and C badly need a "stability layer" to keep programs working over the long term."
""Dangling else" is (or was) perfectly legal when used correctly; the C language was originally designed for use by people who knew what they were doing .... It makes no sense to keep changing this or any other programming language out from under all the millions of programs that have already been written in it."
"In my view it is a CRIME to change an API for any reason when unknown numbers of programs depend on it, and unknown numbers of people depend on those programs."
"What I don't understand is how large segments of the world's economy can be based on software written in a language that keeps changing out from underneath it."
Stricter defaults are valuable so long as you can disable them. I compile with -Wall and -Wextra and persistently find modern third party libraries that fail those checks. If you care about code quality your public library code should be held to a high standard and build without throwing warnings with less permissive compiler settings.
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.
> 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.
All the best for the author. Compiling old programs on newer systems is an exercise in pain. Gcc is becoming increasingly hostile to old programs by dropping support for old C dialects.
I used ckermit on Coherent years ago to log into work. Then work would dial back and allow me to connect to avoid phone charges. good times :)
I even purchased the book to support the project, it had lots of cool info in it.
Eventually I compiled it for Linux when mark Williams closed. I have not had a need for it these days, will need to see if I can do anything I can use it for.
I even purchased the book to support the project, it had lots of cool info in it.
Eventually I compiled it for Linux when mark Williams closed. I have not had a need for it these days, will need to see if I can do anything I can use it for.
glad to see this, I've been worreid about kermit for some time. I still really like using it for serial device connectivity.
https://en.m.wikipedia.org/wiki/Kermit_(protocol)