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,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS 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 09EC51F5AE for ; Fri, 31 Jul 2020 18:22:51 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9E6BD384B00F; Fri, 31 Jul 2020 18:22:49 +0000 (GMT) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) by sourceware.org (Postfix) with ESMTPS id 2D7723857C58 for ; Fri, 31 Jul 2020 18:22:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2D7723857C58 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=columbia.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fd1@columbia.edu Received: from pps.filterd (m0167077.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06VI0hAf014471 for ; Fri, 31 Jul 2020 14:22:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=Vkog+BvnlHUdaNhHCz8hvaNxwhI9ao6pChJF3xNpBUY=; b=Y1luaZzXggEgj35tF9b8rr06N5ybfOxR1Za56Q+eMhK2r4Dv9jT84oezKcgA+9YWWlO6 w08RevzDO/NFb7W1vFZODtJx24WPSxj2yoXLXyQuyTX+JTtCCXJea8DqskzZRX7wCCjo DMnjfx1A6idi4hrp6ncrsmgjQPKLIYXqkYlCDDOlpPGf+aYTbh86DIC9LveMwl3qcVc7 qBPzTSw4cAjq8pPVaPAvIF4QxsG6fcI1hIt0DAv9JRewYHnglyw7FYqULPbnlnid8fGI Y6YS1wx+Zrje3ia6h0QR/TSvhaKktGoh7JjTPoECyhXuHuL2BJKqOeSmD566SHpF7BLZ lg== Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0b-00364e01.pphosted.com with ESMTP id 32jkqr5qjw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jul 2020 14:22:45 -0400 Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06VIMitJ021563 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 31 Jul 2020 14:22:44 -0400 Received: by mail-il1-f200.google.com with SMTP id 65so983169ilb.12 for ; Fri, 31 Jul 2020 11:22:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vkog+BvnlHUdaNhHCz8hvaNxwhI9ao6pChJF3xNpBUY=; b=A423b//zhu05nDywkUI79c1vIkKsS8CfRNN5wiLn3pulTtKQW3fHqCadsCQpHOkiuA b90SvUJdpqUQgPYKgK7a8dkI99xg5UEn6K8zOUja23cDMONkKpAvThDmx/vqVmxg4UG7 wJeRgmRlJNmFBplTMOJTYsKiXueF1MXMja5BH42573M7tNgZf1ArtzYYErkNQcGtWsKS 5WFltOtPnU5Vtv6Hgx6gIjDIlNjCgHGV7bLjvO6jQJciK2tNbJ/NarWpSP7rpgCgS+S3 cHWa16slb+uAKllT313VzGdiV5ocYIvIHhZDTkUeo/V5iOmoXuZ9tMGbpRQsln/P9fId Q/5g== X-Gm-Message-State: AOAM530kEIaHSUSgEXkvIZ9XkMGZ7O3wJrtKNahSmxG0iyv2MSXSW057 jG8HBiPBX+pP6EnS9YZZXp6pC30N3yu02UWN9pY1S9k0aBNnC+wPARBgol5XeO6RP0pC6RMMv4a /1RoFUFLnw3cV/PE/kdphbuhhY6kgwEjLmthi1CXgDuxM X-Received: by 2002:a05:6e02:f14:: with SMTP id x20mr5191274ilj.77.1596219764037; Fri, 31 Jul 2020 11:22:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwR1m08dyowqZrWVtLiHkBN8RgwcuMCOL/D5Ll7TbaVZv9Mk4NZ8DDY1Wq2S9bXVRI4xbaNaKah9BN6sBC1qyA= X-Received: by 2002:a05:6e02:f14:: with SMTP id x20mr5191213ilj.77.1596219763161; Fri, 31 Jul 2020 11:22:43 -0700 (PDT) MIME-Version: 1.0 References: <10CAD3CD-0170-4182-A920-EE825EBAF6B0@rmrco.com> <95d9170b-d925-5037-c841-e1fd17bb680f@cs.ucla.edu> In-Reply-To: From: Frank da Cruz Date: Fri, 31 Jul 2020 14:22:31 -0400 Message-ID: Subject: Re: C-kermit fails To: "Maciej W. Rozycki" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-31_06:2020-07-31, 2020-07-31 signatures=0 X-Proofpoint-Spam-Reason: safe Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 , Frank da Cruz , Mike , GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Fri 32 Jul 2020 Maciej W. Rozycki wrote: > 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? > That's what I have always done since C-Kermit first appeared in 1985, and it's why C-Kermit is so full of #ifdefs. Although I'm not sure I accept it is incumbent on developers to stop using fread because somebody can't be bothered to implement a politically correct way to peek into the buffer to see if any characters are there. This is necessary to prevent the program from blocking on an input request at a time when it might productively be doing something else. Which is a classic problem that must be solved in every terminal emulator. Of course there are more modern ways to write terminal emulators, e.g. using threads or whatever, but these are not available on all the platforms where C-Kermit runs. Not even select() is available on all those platforms. But the whole point of C-Kermit is to not have to write a whole new program for each platform, but to have a single code base that is portable among as many platforms as possible. I have no control over what operating-system makers do (or the makers of glibc), and if they think it's OK to break existing applications I'll have to program around it when I could likely be doing something more useful. But ever since Unix went public, and especially since the free versions appeared, I find that I spend more time redoing everything I already did before than I spend doing anything new. Software development was not like this when computing was dominated by companies like IBM and DEC, who were dedicated to preserving their customers' investments in software because if they didn't, they'd lose those customers. - Frank On Fri, Jul 31, 2020 at 8:41 AM Maciej W. Rozycki wrote: > 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 >