C-kermit fails

[Maciej W. Rozycki]

On Fri, 24 Jul 2020, Frank da Cruz wrote:

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

 I can't speak for other people, but myself I do care, and I also enjoy 
using vintage computers, although maybe not as old as DECSYSTEM-20 (a VAX 
is probably the oldest piece I have).

 Since you already use #ifdefs to provide code alternatives then may I 
suggest that you keep the relevant piece for the systems where the gain 
from using getchar/getc is actually noticeable and switch to documented 
standard interfaces for contemporary systems?

 This way you'll keep the benefits for everyone: much needed performance 
for the old systems and portability for current systems where any gain 
from fiddling with libc internals accidentally exposed is lost in the 
noise?

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

 Yes, this is painful indeed, and much overlooked by software developers 
nowadays IMO.

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

 This is why we have a set of standards for the interfaces we promise to 
support.  Please try and stick to them.

  Maciej