Re: C-kermit fails

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

Somebody else sent a simpler patch, you can see it here:

http://kermitproject.org/ckglibc228.diff

Ever since yesterday I've had mail coming in from people who reported that
different Linux distributors (e.g. Debian, Ubuntu) had dropped C-Kermit
from their packages collection.  They were surprised when apt-get said,
nope, we don't have that.  In some cases, these people are in a big rush
because of some emergency or deadline.  So casually removing something from
your header files is kind of like a COVID-19 virus, it strikes a few people
at first and then starts multiplying, affecting end-users and developers
alike.  The cardinal rule for OS developers was once "maintain backwards
compatibility" or more simply stated, "do no harm".  I've been a programmer
since 1965 if you can believe it, and have watched helplessly as this rule
started being thrown out the window starting around 1990.

I just put up a new C-Kermit version that has a simpler patch, please let
me know if you see a problem with it; it was sent to me by someone else; at
present I don't have access to anything but Red Hat and NetBSD:

http://kermitproject.org/ckglibc228.diff

I'm going to be forced to turn this into a real release ASAP, long before I
was planning to, and I would hope that the Linux packagers who tossed
C-Kermit will put it back once this settles down (and better still, that
they contact me when they find out about a problem).  You have only heard
about C-Kermit so far, but how do you know other applications won't be
affected?  It's better to leave things in, especially in libc.  If we can't
depend on libc, what's the use in even trying to write stable software?

Anyway another problem with your patch is, believe or not, C-Kermit is
written to be buildable on platforms going back to the 1970s (Bell Research
Unix V8) and 80s (HP-UX 5.0) so compound #if statements can't be used.

I'd encourage you to put the missing symbol (and code supporting it) back
in glibc and be more careful about removing things that "nobody uses" or
"nobody *should* use".  But since the new glibc is already out in the wild,
I'll still have to support the systems that have the missing symbol from
now on, just like I still support dentists' offices that have ancient
versions of SCO Xenix.

- Frank

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

> On 7/24/20 10:36 AM, Zack Weinberg wrote:
> > The symbol that was removed (_IO_file_flags) was never a documented
> > part of the stdio interface.
>
> True, though lots of programs want to know about stdio readahead and it's
> unfortunate that glibc and other C libraries don't provide a documented
> way to
> get it.
>
> We have a Gnulib module for discovering stdio readahead. As seen here:
>
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/freadahead.c#n36
>
> Gnulib uses the guard "#if defined _IO_EOF_SEEN || defined
> _IO_ftrylockfile ||
> __GNU_LIBRARY__ == 1" to be as portable as possible to various glibc-like
> libraries, so I suggest the attached minimal patch to C-Kermit.
>