Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Two questions on arrays with size defined by variables
Date: Mon, 10 Feb 2025 07:27:22 +0100
Organization: A noiseless patient Spider
Lines: 82
Message-ID: <voc68c$13fkt$1@dont-email.me>
References: <vo9mns$gsd7$1@dont-email.me> <vo9nn3$gtph$1@dont-email.me>
 <vo9u0u$i0n8$1@dont-email.me> <voae3a$2rke4$1@paganini.bofh.team>
 <voao29$o6uh$2@dont-email.me> <87bjvar83h.fsf@nosuchdomain.example.com>
 <vobna3$tmev$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 10 Feb 2025 07:27:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7ae7436750940773d2334410c5fdf1e5";
	logging-data="1162909"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19wJeYBbRnAF3kcSRAbpBu5"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:/IBJc1jJyeLZvdoGFHcc+jboPYA=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vobna3$tmev$1@dont-email.me>
Bytes: 3944

On 10.02.2025 03:12, Janis Papanagnou wrote:
> On 10.02.2025 00:50, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> [...]
>>> I had other languages in mind.[*]
>>>
>>> Janis
>>>
>>> [*] For example Simula:
>>>
>>> begin
>>>     integer n;
>>>     n := inint;
>>>     begin
>>>         integer array arr (1:n);
>>>         arr(5) := 9;
>>>     end
>>> end
>>>
>>> (Which is also understandable, since in Simula declarations must appear
>>> before statements in any block.)
>>
>> Apparently Simula doesn't allow variables to be initialized in their
>> declarations. 
> 
> The Cim compiler I use actually supports a constant initialization -
> but I'm positive this is non-standard! - like
> 
> begin
>     integer n = 10;
>     integer array arr (1:n);
>     arr(5) := 9;
> end
> 

I should have noted that this (non-standard) syntax doesn't really
address the problem (since you have just a named constant that you
may use in several places, but the array is *not* really dynamic,
its memory demands are fixed and known for that block).

I think the primary point for an explanation of the necessity of a
block structure is different. - It is typical that stack memory is
allocated when a block is "entered". For the stack allocation the
size of all local objects should be known. But in the first example
above the outer block has only knowledge about the size of the 'n'
integer variable, but without a concrete value for 'n' we don't
know how many space the dynamic array will need. But if we open a
new (subordinated) block the array size is determined if declared
there.

BTW, this is also true for Algol 60, which is effectively a subset
of Simula.

> 
>> Because of that, `n := inint;` (where inint is actually a
>> call to a value-returning procedure) is a separate statement.  If
>> Simula supported C-style initializers, then presumably the inner block
>> would not be needed:
> 
> Indeed. (See non-standard example above.)
> 
>>
>>     begin
>>         integer n := inint;
>>         integer array arr (1:n);
>>         arr(5) := 9;
>>     end
>>
> 
> This is not possible because 'n' isn't a constant here (and 'inint' is
> a function, as you say). - So you're correct that the block would not
> be an inherent necessity for that declaration [with Cim compiler].

So, given my above stack memory argumentation, I'd have to withdraw
my agreement; and not only because it's irrelevant (in several ways).

> A general statement for the standard Simula language cannot be given,
> though, since it's undefined.
> 
> Janis
>