Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: alt.folklore.computers,comp.os.linux.misc
Subject: Re: The joy of FORTRAN
Date: Mon, 30 Sep 2024 12:35:48 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vde5v2$fg8s$1@paganini.bofh.team>
References: <pan$96411$d204da43$cc34bb91$1fe98651@linux.rocks> <5mqdnZuGq4lgwm_7nZ2dnZfqnPSdnZ2d@earthlink.com> <vcub5c$36h63$1@dont-email.me> <1r0e6u9.1tubjrt1kapeluN%snipeco.2@gmail.com> <llgckbF2sq0U3@mid.individual.net> <vcuupr$2pg09$1@paganini.bofh.team> <156256844.748909906.434683.peter_flass-yahoo.com@news.eternal-september.org> <vd0p06$3knoh$6@dont-email.me> <1696219735.749088927.121438.peter_flass-yahoo.com@news.eternal-september.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Sep 2024 12:35:48 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="508188"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 2778
Lines: 29

In alt.folklore.computers Peter Flass <peter_flass@yahoo.com> wrote:
> 
> Another thing PL/I got from COBOL is “natural” string handling. Assign a
> short string to a larger any the result is automatically blank-padded.
> Assign a longer to a shorter and the longer is truncated, with or without
> an error.

In my world blank padding is simply wrong result.  Truncation too.
To have natural handling language needs to track actual lengths
(and signal (catchable) error on overflow).  And such natural
handling may be quite inefficient.  I recently looked at code
generated by GNU Pascal compiling for a 32kB machine.  String
handling needed about 60kB for string buffers (30 buffers 2kB
each) and the file did not compile.  Compiler handling string
buffers in smarter way probably could reuse some buffers.
But there were several copy operations (or rather concatenations)
and some string variables were used multiple times, so even
with good optimizer for string operations the code would still
be rather inefficient.

To put it differently: natural string operations work nicely
if you have big machine with lot of memory and machine cycles
to waste.  But if you need efficient code for small machine,
then you want single buffer which is modified in place.

And of course, on big modern machines people use dynamic memory
allocation.

-- 
                              Waldek Hebisch