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.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 B467E1F5AE for ; Fri, 31 Jul 2020 12:41:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 732E03861016; Fri, 31 Jul 2020 12:41:11 +0000 (GMT) Received: from cvs.linux-mips.org (eddie.linux-mips.org [148.251.95.138]) by sourceware.org (Postfix) with ESMTP id 915F43851C17 for ; Fri, 31 Jul 2020 12:41:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 915F43851C17 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-mips.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=macro@linux-mips.org Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23991307AbgGaMlE0BFkI (ORCPT ); Fri, 31 Jul 2020 14:41:04 +0200 Date: Fri, 31 Jul 2020 13:41:04 +0100 (BST) From: "Maciej W. Rozycki" To: Frank da Cruz Subject: Re: C-kermit fails In-Reply-To: Message-ID: References: <10CAD3CD-0170-4182-A920-EE825EBAF6B0@rmrco.com> <95d9170b-d925-5037-c841-e1fd17bb680f@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Liam Stitt , Mike , GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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