C-kermit fails

[Zack Weinberg]

On Fri, Jul 24, 2020 at 12:29 PM Mike <michael@rmrco.com> wrote:
> Frank da Cruz wrote:
>> Apparently glibc was changed in a way that broke C-Kermit,
>> so the reaction of Linux packagers was to remove C-Kermit
>> from their distribution.  Somebody else wrote me about
>> this earlier today concerning Debian:
>>
>>> Debian's "solution" to the problem was to drop the package
>>> after the initial bug was filed, without contacting
>>> upstream about it at all(!), hence presumably why this is
>>> news to you. I've done some digging, and it appears glibc
>>> is to blame (they removed an interface in 2.28). This
>>> patch from gentoo, which also apparently didn't think
>>> about telling you (sigh) appears to fix it:
>>>
>>> https://685096.bugs.gentoo.org/attachment.cgi?id=589698
>>
>> I have verified that it compiles now.
>>
>> The right thing to do would be to encourage the glibc
>> people to put back the symbol that they deleted.  Because
>> if this change broke C-Kermit, it's likely to have broken
>> a lot more applications.

The symbol that was removed (_IO_file_flags) was never a documented
part of the stdio interface.  The code that is gated on its definition
uses other undocumented internals of stdio; we do in fact have plans
that may cause those symbols to disappear as well.  This thread is the
first we've heard about C-Kermit depending on it, and we haven't heard
of *any* other application that does.  (Although it's possible that
redistributors of other applications didn't bother telling us about
problems either.)

The right fix for upstream C-Kermit would be to bypass stdin
altogether and use only read(0, &ch, 1), together with the <termios.h>
interfaces for querying the kernel-side input buffer. I looked at the
code briefly and it seems like coninc() and in_chk() already do this.
It's not clear to me why cmdgetc() ever uses getc(stdin) and/or
getchar().

zw