C-kermit fails

[Frank da Cruz]

Sorry, I pasted a wrong URL into my last message; the new C-Kermit version
(for testing only), 9.0.305 Alpha.01 is here:

http://kermitproject.org/ckdaily.html

- Frank

On Fri, Jul 24, 2020 at 3:41 PM Frank da Cruz <fdc@columbia.edu> wrote:

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