Hi,

I tested RC1 using one of my codes and ran into an internal error. I was able to reduce the code to the following.

Free Pascal Compiler version 2.6.0rc1 [2011/10/15] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling InternalError.dpr
InternalError.dpr(21,3) Fatal: Internal error 201103063 Fatal: Compilation aborted

--- Code, start ---

{$IFDEF FPC}
  {$MODE Delphi}
{$ENDIF}
program InternalError;
procedure SetArray({var}out SingleArray: array of Single; const Value: Single);
var
  I: Integer;
begin
  for I := Low(SingleArray) to High(SingleArray) do
    SingleArray[I] := Value;
end;
var
  ValuesBuffer: array of Single;
begin
  SetLength(ValuesBuffer, 5);
  SetArray(ValuesBuffer, 5.7);
end.

--- Code, end ---

The error is at the beginning of SetArray() call.

I see that the real error is in my code since the procedure parameter has to be 'var' and not 'out' otherwise the dimension which is set outside will not reach the procedure. But the compiler shouldn't stop with an internal error. If it is changed to 'var' it compiles.

FPC 2.4.4 just compiles it.

Regards

Michael

25.11.2011 13:36, Michael Müller пишет:

I guess this one is for me to fix.

I see that the real error is in my code since the procedure parameter has to be 'var' and not 'out' otherwise the dimension which is set outside will not reach the procedure. But the compiler shouldn't stop with an internal error. If it is changed to 'var' it compiles.

Frankly speaking, I doubt that. 'out' in this case likely refers to elements of dynamic array, not to array itself. If it was e.g. 'array of ansistring' then all its elements should be finalized before the call, then pointer to first element and length passed to callee.

FPC 2.4.4 just compiles it.

But it may produce incorrect code when managed types are involved, see http://bugs.freepascal.org/view.php?id=18859

Regards,
Sergei

25.11.2011 15:49, Sergei Gorelkin пишет:

Fixed in r19684.
If possible, please consider merging the fix to 2.6.

Regards,
Sergei

Hi Sergei

Thanks for the fix. Hopefully it finds it way into 2.6.

> I see that the real error is in my code since the procedure parameter has to be 'var' and not 'out' otherwise the dimension which is set outside will not reach the procedure. But the compiler shouldn't stop with an internal error. If it is changed to 'var' it compiles. > Frankly speaking, I doubt that. 'out' in this case likely refers to elements of dynamic array, not to array itself. If it was e.g. 'array of ansistring' then all its elements should be finalized before the call, then pointer to first element and length passed to callee.

After your statement I played a little bit and it seems that you are right. When using 'out' the length of the array reaches the procedure. But what surprises me much more is that even values of the array reach the procedure. I added a loop at the beginning of the procedure that print the array before the (new) value is set and it shows the values that were set outside the procedure after SetLength(). For an array of String the elements are emptied (as you stated too). Does this mean that reference counted elements are emptied and the others not? Beside that what is than the difference between 'out' and 'var'? (I tested this also with Delphi 2009 with exact the same behaviour). The Delphi help mentions that for 'out' parameters the referenced variable is freed (or so) when it is given to the routine (I have only a German help otherwise I would show the text here). This is exact the behaviour that I expected. So for me it sounds that even Delphi is not doing it as stated in the documentation. Where is my understanding wrong here?

Regards

Michael

Michael Müller wrote

Does this mean that reference counted elements are emptied and the others not?

Yes.

Beside that what is than the difference between 'out' and 'var'?

If you enable hints, the compiler will print a hint if it detects you passing a potentially uninitialized variable to a "var" parameter, while it won't print such a warning if you pass it to an "out" parameter. Additionally, if you use the -gt command line option then the compiler will overwrite the contents of (non-reference-counted) out-parameters in the function entry code. This switch will do nothing for open array parameters though, because it lacks support for using the hidden "high" parameter to determine the bounds of the array at run time.

Jonas

But inside the routine with "out" parameter I had expected to get the same warning ;-). But this was before I learnt that at least something of an "out" parameter reaches the routine.

Why is this 'passing a potentially uninitialized variable to a "var" parameter' ('bla does not seem to be initialized') message a warning for arrays and a hint for basic types?

Additionally, if you use the -gt command line option then the compiler will overwrite the contents of (non-reference-counted) out-parameters in the function entry code. This switch will do nothing for open array parameters though, because it lacks support for using the hidden "high" parameter to determine the bounds of the array at run time.

I don't understand this restriction. In the code High() works for open arrays at run time.

Regards

Michael

Michael Müller wrote

> Additionally, if you use the -gt command line option then the compiler will overwrite the contents of (non-reference-counted) out-parameters in the function entry code. This switch will do nothing for open array parameters though, because it lacks support for using the hidden "high" parameter to determine the bounds of the array at run time. I don't understand this restriction. In the code High() works for open arrays at run time.

I suppose that the "-gt" code is generated on a lower level, so it can't just use High(), but would need to access the hidden parameter that contains the array length directly. And that part is simply not implemented, so open arrays are not handled.

Regards,
Sven

You do get a warning if you use an "out" parameter inside a routine without first writing to it.

Why is this 'passing a potentially uninitialized variable to a "var" parameter' ('bla does not seem to be initialized') message a warning for arrays and a hint for basic types?

It's only a warning for dynamic arrays. And the cause is a side effect of the way a "dynamic array" is internally converted to an "open array". It shouldn't be very difficult to fix that though.

I don't understand this restriction. In the code High() works for open arrays at run time.

See Sven's answer.

Jonas

28.11.2011 14:26, Sven Barth пишет:

Yes, this is simply an unimplemented feature.

Sergei

But only if you try to access an array element. I would have expected to get such a warning also when using Length(), Low() or High() (which I did in my original example). But I assume this difference is coming from how an array is handled. Even without using SetLength() I assume that just by declaring an array variable there is an internal structure that contains the array length field and the pointer to the element block. And there is no possibility to differ between an uninitialized (since initialized internally) and a SetLength(, 0) or array := nil. Is this correct?

Regards

Michael

Probably, yes. The checks for uninitialized values in FPC is are quite ad hoc en very much based on "best effort" rather than on any kind of guarantees.

No. The compiler does not take into internal initializations for "uninitialized" checks.

Jonas