> On Apr 3, 2020, at 10:09 PM, Sven Barth wrote:
>
> No. The "[...]" for an open array parameter means "open array constructer"
> *not* "dynamic array constructor". And this on-the-fly open array is in fact
> constructed on the stack.
Ok, I see now. Excellent. I thought this was another dyn
Ryan Joseph via fpc-pascal schrieb am
Fr., 3. Apr. 2020, 14:33:
>
>
>
> > On Apr 3, 2020, at 3:43 PM, Sven Barth
> wrote:
> >
> > They are neither. They are simply a pointer to the first element and a
> hidden size argument. For the pointer it is not important where it comes
> from: a single ele
> On Apr 3, 2020, at 3:43 PM, Sven Barth wrote:
>
> They are neither. They are simply a pointer to the first element and a hidden
> size argument. For the pointer it is not important where it comes from: a
> single element, a dynamic array, a static array.
>
Ah, I see. In the example belo
Op 2020-04-01 om 23:49 schreef Bart via fpc-pascal:
I think I'll put this under a special porunidle option in trunk and fpc
3.2.0 , so to only trigger this when needed.
Hmm..
porunidle -> poRunIdle (to be consistent in namegiving)?
Done.
___
fpc-pa
Op 2020-04-02 om 08:45 schreef Gabor Boros:
2020. 04. 01. 17:21 keltezéssel, Marco van de Voort írta:
But at least FPC3.2.0rc1 has a rewritten tprocess/runcommand that
makes this fixable without source changes and recompilation, look at
the next example:
It's fast but FPC's help not showed
Ryan Joseph via fpc-pascal schrieb am
Fr., 3. Apr. 2020, 04:13:
>
>
> > On Mar 16, 2020, at 5:40 AM, Sven Barth
> wrote:
> >
> > The message of the compiler is a bit misleading. It's a *dynamic* array
> that is created there, not an *open* array. Open arrays only exist when
> being passed direct
