Re: C-kermit fails

[Frank da Cruz <fdc@columbia.edu>]

 The reason I use getchar/getc is that Kernighan and Plauger recommend it
because it's buffered and avoids needless context switches.  I'm sure you
guys don't care much about the efficiency of character loops, but some of
the ancient machines where C-Kermit runs are pretty slow.  Computers and
operating systems are supposed to serve the needs of human beings.  But
when you make non-backward-compatible changes to operating systems that
break existing applications, you force people to stop what they are working
on (a cure for some deadly disease, perhaps) and search for a new version
of the application they were using that "complies" with the new "standard",
and then, not finding one, hunt down and contact the developers, if they
are still alive, and beg them to "update" their software.  When you think
of a more "correct" way of accomplishing something, by all means add it to
the system, but without removing the old way, so existing software
continues to run.  Unix is supposed to be a family of operating systems
among which software source code is portable, allowing a degree of freedom
in computer purchases.  It's not perfect, to be sure, as anyone who looks
at the #ifdef soup in the C-Kermit code can attest, but it sure beats the
situation back in the early 80s, when most universities had DECSYSTEM-20s
and all the software was written in languages that didn't exist on any
other platform and certainly don't exist today (Macro-20, SAIL, BCPL..).
At Columbia U the transition from DEC-20 to Unix (DEC Ultrix at first) was
a massive job; NO software could be ported, all the applications had to be
rewritten from scratch, in C of course.  But going from Ultrix to SunOS to
Solaris and finally to Linux was relatively painless.  So I think the
objective of Unix OS developers should be *towards* compatibility rather
than away from it, as seems to be the case with glibc.

- Frank

On Fri, Jul 24, 2020 at 5:07 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 7/24/20 12:41 PM, Frank da Cruz wrote:
> > So casually removing something from
> > your header files is kind of like a COVID-19 virus
>
> This strikes me as a bit unfair, as those parts of the header files have
> always
> been explicitly private.
>
> Zack is right that C-Kermit's best bet for portability/reliability is to
> remove
> uses of getchar/getc. This would render unnecessary that unportable cruft
> in
> ckucmd.c.
>
> If age and experience is a qualification for an opinion here, I will
> confess
> that I've also been writing code since the 1960s, and my opinion is that
> programs that stick their fingers into stdio's internals bear the
> responsibility
> for the consequences. And I write this despite helping to maintain code
> (Gnulib)
> that does exactly what C-Kermit's ckucmd.c does. When the new glibc came
> out the
> Gnulib developers didn't complain that glibc's changes were "like a
> COVID-19
> virus"; we simply adapted Gnulib and moved on.
>