From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS,URI_HEX shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1991A1F5B1 for ; Fri, 24 Jul 2020 17:37:04 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 13232385703C; Fri, 24 Jul 2020 17:37:02 +0000 (GMT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by sourceware.org (Postfix) with ESMTPS id BF1083857C64 for ; Fri, 24 Jul 2020 17:36:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BF1083857C64 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=panix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zackw@panix.com Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4BCxGM2QLqzsvX for ; Fri, 24 Jul 2020 13:36:59 -0400 (EDT) Received: by mail-ed1-f47.google.com with SMTP id b13so5195626edz.7 for ; Fri, 24 Jul 2020 10:36:59 -0700 (PDT) X-Gm-Message-State: AOAM532d4lIZ+nJYo1lXtAl0Nq0n5g8Xn+OlrPDF18YrDc2vsj+/roJr VrkocPMBij3Vl1mI02tEPCeEMIqTJpEFafZIjZI= X-Google-Smtp-Source: ABdhPJxVwGum2PV2SWi8otCnKXgR6VAtdSg6fNXQatSn0YuG6CAmHvJvjGB/KH4UAX0qW5LO5PPvWF06/7xPo2yV9XM= X-Received: by 2002:a05:6402:2037:: with SMTP id ay23mr3909872edb.48.1595612218517; Fri, 24 Jul 2020 10:36:58 -0700 (PDT) MIME-Version: 1.0 References: <10CAD3CD-0170-4182-A920-EE825EBAF6B0@rmrco.com> In-Reply-To: <10CAD3CD-0170-4182-A920-EE825EBAF6B0@rmrco.com> From: Zack Weinberg Date: Fri, 24 Jul 2020 13:36:47 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: C-kermit fails To: Mike , Frank da Cruz Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Fri, Jul 24, 2020 at 12:29 PM Mike 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 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