From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30088 invoked from network); 6 Jul 2021 05:59:14 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Jul 2021 05:59:14 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1F5949C9FE; Tue, 6 Jul 2021 15:59:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id F1D769C9F2; Tue, 6 Jul 2021 15:58:42 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=servium.ch header.i=@servium.ch header.b="vwIB3UCf"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2354D9C9F2; Tue, 6 Jul 2021 15:58:40 +1000 (AEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 31E989C9F0 for ; Tue, 6 Jul 2021 15:58:39 +1000 (AEST) Received: by mail-pg1-f169.google.com with SMTP id d12so20385985pgd.9 for ; Mon, 05 Jul 2021 22:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=servium.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+codoofdjc7YvXPx3phdvVBLRzRG3sjL+Dn1Mkf+LE=; b=vwIB3UCfPWwCx0mxC3G0tfTZkPcFaU3u0S55G/6a4fpXqddrJOnecjiHg7Bhk/qrlT g18RnaojISUBUGXBI9y2dzVoUdxzVZDO/af8ZxTpuXXJQFQn9aOtoZZkP9OJ8R2qKq4b pSgQCDbCtbhBO1YFimEYjizF3rtaBm3DcCUf8= 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=6+codoofdjc7YvXPx3phdvVBLRzRG3sjL+Dn1Mkf+LE=; b=q1h1X00F5FyKDPuKxHS1C8AKYp8gryyM18Wi1BCw1uEsKmbiFVETe7XDhmI1iD1F/J S8euPtF2catl+4XS12RPs9i6O785cFxO1x/oiL9Tw/Yowgr1rYh9q3jkC6syoyNkhGn+ QFrZit/4O6AioIMU3dHaLXfwpS+RhBmBPb0h7b9GxFbddkpDvQ5UaK8h7AH8toB012+U Id6Q6fdvp1AFMnmGVt5B7+Yok+65qsrNn/S2uf4tzw3fINpyN0ajObtA6VrT79pLQtru YgTslXuU/295PLVZofuKVsF9Mo+PgFCBvi5Ps1fK44SSB+GI+j2/sCjxvu0kpVQyN011 AchQ== X-Gm-Message-State: AOAM532o7BczEAWtN54FtllWcrVMEGDP63oT8lOyLaZvaHRe6/8dMfm5 aeD9pCLNmCzgL4lwOIGlaP8r3CxwEwux/7889U/MzQ== X-Google-Smtp-Source: ABdhPJwUHKG7fauFMjnNtA4HTce+l9yAVCDJ1IsM3bCP9uGASvblFsZ0+iGqv3s1udpzPb7u274lP24UE+OKIzyd3HE= X-Received: by 2002:aa7:8439:0:b029:313:1d31:1318 with SMTP id q25-20020aa784390000b02903131d311318mr18278462pfn.24.1625551118473; Mon, 05 Jul 2021 22:58:38 -0700 (PDT) MIME-Version: 1.0 References: <20210702213648.GW817@mcvoy.com> <20210705002119.GL817@mcvoy.com> <20210705034751.GU817@mcvoy.com> <20210705134522.nzyIC%steffen@sdaoden.eu> In-Reply-To: From: Rico Pajarola Date: Mon, 5 Jul 2021 22:58:27 -0700 Message-ID: To: Dan Stromberg Content-Type: multipart/alternative; boundary="000000000000fb2b6105c66e1c62" Subject: Re: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000fb2b6105c66e1c62 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 5, 2021 at 9:37 PM Dan Stromberg wrote: > Supposedly even Borland's TurboPascal had better strings than vanilla > Pascal. > and then they used only 1 byte for the string length, limiting the max length to 255, which made it completely pointless, because the moment you had some real world data, you were back in manage-my-own-pointers-to-arrays-of-chars-land. (I loved Turbo Pascal, it's the first language I used for "serious" programming. They got a lot of things right, but strings were emphatically not among those things). My other gripe was that Turbo Pascal programs spend half their time on pointer normalization (every pointer access has a preamble that makes sure that the offset is < 16). I'd really love to understand why on earth they decided to do it that way (I'm sure there's a reason, I just fail to see it). It's not like anyone could do pointer arithmetic behind the compiler's back... it slows things down, and it's probably the reason why an equivalent Turbo C program is only half the code size. And it makes it impossible to do clever things with segment registers (18 year old me didn't like that). --000000000000fb2b6105c66e1c62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 5, 2021 at 9:37 PM Dan Stromberg = <drsalists@gmail.com> wrot= e:
=
Supposedly even Borland's TurboPascal h= ad better strings than vanilla Pascal.
and then they used only 1 byte for the string length, limiting the max l= ength to 255, which made=C2=A0it completely pointless, because the moment y= ou had some real world data, you were back in manage-my-own-pointers-to-arr= ays-of-chars-land.

(I loved Turbo Pascal, it's= the first language I used for "serious" programming. They got a = lot of things right, but strings were emphatically not among those things).=

My other gripe was that Turbo Pascal programs spe= nd half their time on pointer normalization (every pointer access has a pre= amble=C2=A0that makes sure that the offset is < 16). I'd really love= to understand why on earth they decided to do it that way (I'm sure th= ere's a reason, I just fail to see it). It's not like anyone could = do pointer arithmetic behind the compiler's back... it slows things dow= n, and it's probably the reason why an equivalent Turbo C program is on= ly half the code size. And it makes it impossible to do clever things with = segment registers (18 year old me didn't like that).



--000000000000fb2b6105c66e1c62--