From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.63.41 with SMTP id z29mr37167687yhc.15.1415807358336; Wed, 12 Nov 2014 07:49:18 -0800 (PST) X-Received: by 10.50.114.134 with SMTP id jg6mr468620igb.13.1415807358236; Wed, 12 Nov 2014 07:49:18 -0800 (PST) Path: border1.nntp.dca1.giganews.com!nntp.giganews.com!i13no1107823qae.0!news-out.google.com!ks2ni18691igb.0!nntp.google.com!hl2no562764igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 12 Nov 2014 07:49:17 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <487cd979-9693-478c-9eac-268e1a0d37c8@googlegroups.com> Subject: Re: Surprising behaviour of strings.fixed.overwrite From: Adam Beneschan Injection-Date: Wed, 12 Nov 2014 15:49:18 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:190480 Date: 2014-11-12T07:49:17-08:00 List-Id: On Wednesday, November 12, 2014 2:49:33 AM UTC-8, Markus Sch=F6pflin wrote: > Well, I would have expected the output to be >=20 > @@@@@6 > @@@@@5 >=20 > But it is: >=20 > @@@@56 > @@@@@5 >=20 > Which is correct according to the definition of overwrite, but neverthele= ss I=20 > find this extremely surprising. >=20 > Am I alone in this? >=20 > Or can anyone please the rational on defining the behaviour of overwrite = as it is? I agree that it's odd. However, it does make some sense that the Overwrite= *function* would return a 7-character String in the first case, although t= hat also isn't the effect I would have expected at first (since the charact= ers that get appended to the string aren't overwriting anything). I can im= agine how this kind of result from the function would be useful. I'm guess= ing, though, that this possible behavior of the function was missed when it= was decided to define the procedure's semantics in terms of the function. -- Adam