Hmmm... Just pure curiosity:
I am getting a warning "Variable does not seem to be initialized" on a code from FreePascal RTL guide:

Var Fin, fout : File;
    NumRead,NumWritten : Word;
    Buf : Array[1..2048] of byte;
    Total : Longint;
begin
  Assign (Fin, Paramstr(1));
  Assign (Fout,Paramstr(2));
  Reset (Fin,1);
  Rewrite (Fout,1);
  Total:=0;
  Repeat
    BlockRead (Fin,buf,Sizeof(buf),NumRead); // <-- Warning here (buf)
    BlockWrite (Fout,Buf,NumRead,NumWritten);
    inc(Total,NumWritten);
  Until (NumRead=0) or (NumWrittenNumRead);
[snip]

Address: http://www.freepascal.org/docs-html/rtl/system/blockread.html

I have used similar code for ages and had no problems, but... Am I missing something? Should the buf be initialized (and if so - how) somewhere before?

TIA
Mike

Micha³ Wo¼niak wrote

Hmmm... Just pure curiosity: I am getting a warning "Variable does not seem to be initialized" on a code from FreePascal RTL guide:

Note that it is written "does not SEEM". The code is OK IMHO. Warnings aren't always right -- for example if we have a function with many parameters, and one of the descendant classes implements a overriden function that uses part of the parameters you'll also get a warning, despite that it's ok.

At your service,
Kornel Kisielewicz (charonATmagma-net.pl)
"11 years and no binary. And it's not vapourware" -- Igor Savin

There are no warning/notes when compiled with 1.9.8.

Kornel Kisielewicz wrote

Note that it is written "does not SEEM". The code is OK IMHO.

As I said - pure curiosity. Besides, we all know the dream of a warning-free compilation. :)

Thanks
Mike

Michał Woźniak wrote

As I said - pure curiosity. Besides, we all know the dream of a warning-free compilation. :)

If you just want to feel nice with your code, you can disable the warnings at this piece of code, and re-enable it after, but take care to not change the code and make the warning become true =]

Hi Peter,

Peter wrote

> Hmmm... Just pure curiosity: > I am getting a warning "Variable does not seem to be initialized" on a > code > from FreePascal RTL guide:

...

> BlockRead (Fin,buf,Sizeof(buf),NumRead); // <-- Warning here (buf)

There are no warning/notes when compiled with 1.9.8.

This is true, but there should be a warning. With other words, there are two bugs (or missing features).

BlockRead is declared as

Procedure BlockRead(var f:File;var Buf;count:Word;var Result:Word);[IOCheck];

var do mean, Result is a in/out parameter, it should be initialized before the call. Actually Result is a out-only parameter, therefore the declaration should be:

procedure BlockRead(var f: File; out Buf; Count: Word; out Result: Word); [IOCheck];

BTW: I don't have found [IOCheck] in the documentation, maybe it should be described for programmers, which want to write file handling functions which use the IOResult aka InOutRes error mechanism.

wkr Peter.

BlockRead (Fin,buf,Sizeof(buf),NumRead); Should the buf be initialized (and if so - how)

Maybe like this:
  FillByte(buf, Sizeof(buf), 0);

I tried the blockread example with FPC
v1.0.10, v1.9.6, v1.9.4, and v1.9.8
and none of them gives a warning here.

However, the example below gives me a similar warning with 1.9.8, but not 1.9.6:

program vdnstbi;
var
  s:string;
begin
  str(16, s); // Variable "s" does not seem to be initialized
  WriteLn(s);
end.

Does "S" really need to be initialized ?

IMO, it is better/easier/safer to simply initialize the variable than to disable the warning.

- Jeff

No, that is an error in the compiler. I don't know whether it has already been fixed in the mean time.

Jonas

Hi Jonas,

This is not a error, the hint would be OK, at least in Delphi mode. See my other mail.

The error is in the RTL, the declaration should be

procedure int_str(l: longint; out s: string);

instead of

procedure int_str(l: longint; var s: string);

I don't know whether it has already been fixed in the mean time.

This would don't be a fix, it would be the removing of a useful feature. Or with other words, the symptoms will be removed instead of the real 'problem'.

wkr Peter.

Hi Jeffrey,

Jeffrey wrote

However, the example below gives me a similar warning with 1.9.8, but not 1.9.6:

I don't get such a warning with a version some days ago.

It is the same problem like BlockRead. In TurboPascal there exist only two variants of parameters, call by value and call by reference. Call by value parameters are always input-only parameters. Call by reference parameters can be input-only parameter, input/output parameter or output-only parameter, the compiler can not differentiate this.

Since Delphi there exists two more parameter variants: const and out. const do mean, that the function don't change the parameter, it is input-only parameter. out do mean, that the parameter is a output-only parameter. Now the compiler can differentiate and generate dependable hints.

I don't know, whether other compiler modes support const and out. If yes, the RTL/FCL/LCL functions should use it. This do mean e.g.

procedure int_str(l: longint; out s: string);

instead of

procedure int_str(l: longint; var s: string);

wkr Peter.

I don't know, whether other compiler modes support const and out. If yes, the RTL/FCL/LCL functions should use it. This do mean e.g.

For compatibility we can't do this. Delphi also doesn't warn. And making the warning dependent on the compiler mode will make things too complex. Because it then dependents on the compiler mode used to compile a used unit that contains a function and not on the compiler mode used in the current unit.

Hi Peter,

Peter wrote

> I don't know, whether other compiler modes support const and out. > If yes, the RTL/FCL/LCL functions should use it. This do mean e.g. For compatibility we can't do this. Delphi also doesn't warn.

This is not really a good argument. FPC generate several hints, which are not generated by Delphi and which are useful.

And making the warning dependent on the compiler mode will make things too complex. Because it then dependents on the compiler mode used to compile a used unit that contains a function and not on the compiler mode used in the current unit.

The problem is, that only the OBJFPC and Delphi modes support the out parameter. This prevent a simple solution.

BTW: This need to be documented, at least in the Reference guide Chapter 10 (Using functions and procedures / Parameter lists / Out parameters), maybe in the Programmers manual too.

The problem, you describe above could be solved relative simple, even the solution is more complex. I don't know any details of the compiler, but I assume, that internally the compiler use a identical structure to manage the parameter lists for all compiler modes. The compiler can analyse the function and determine, whether a var parameter is a in, a in/out or a out parameter and modify the parameter list corresponding. This enable to generate correct hints. As a side effect of such a analyse, FPC could generate hints regarding unneeded assignments, like in Delphi:

var
  i: Integer;
begin
  i := 1;   <--- assigned value not used
  i := 2;
...

And additionally the compiler could generate hints to change a var parameter to a const or out parameter in OBJFPC or Delphi mode.

Because I know your standard answer and don't accept it, is there any suggestion list, similar to the bug list?

wkr Peter.

Good point. I will do this.

You can enter a 'wish-list' item in the bug list. (it's the Category)

Michael.

This is not possible when the parameter is passed as var parameter to another procedure that is external.

Lucky enough not, because then ppl will start wishing everything.

The two most important rules about fpc:
- We need to have fun in making FPC
- We have limited time

When we don't like something or find it low priority like this don't expect anything from us. Sending a patch to implement the missing feature that you want will increase the chance that it'll be added to FPC.

Hi Peter,

I know. But why I should explain it more detailed, if you anyway disapprove such suggestions. :-(

q.e.d.

wkr Peter.

Most ppl want compatibility with Delphi. When we add a warning for uninitialized var parameters then there will be a lot of bug reports that Delphi doesn't warn in those cases and we will have to reject the bug report and explain it everytime.

Hi Peter,

Why do you annoy me?

In the last weeks we have had four discussions about hints.

The first problem was a bug and is solved.

Second: 'Type size mismatch, possible loss of data / range check error' if I assign a double value to a single variable (resp. extended to single or double). Your answer:

: Hints should not be enabled by default. They are only provided to : help finding errors.

and later

: You are welcome to provide a clean solution (and patch) to hide : hints. For us it has low priority.

Third: 'Parameter xxx not used'

Your answer:

: For us compiler-developpers it has low priority, IOW don't expect : changes soon if we don't get any patches to support toggling specific : Hints on/off.

Mabe you don't know it, but both hints are never generated by the Delphi compiler. Beside that all three problems and certainly few more could be solved with one common solution, which I have described already. But why anybody should have any interest to develop a solution, if he read statements like: "Sending a patch to implement the missing feature that you want will increase the chance that it'll be added to FPC."

wkr Peter.

Does anybody here on this list want the hints off by default? I don't. Definetely, a possibility to switch hints on/off (with the latter as default) would be great, but if it is not available.

It is also clear to me that, concerning hints, there is no such thing as Delphi-compatibility. Why bother, for god's sake? Errors - that's obvious, warnings - ok, but hints?.. The more, the better, as they allow you to write better code, don't they?
If Delphi hasn't got some hints FPC has, that's Delphi's problem, not FPC's.

Just my three pence.

Cheers
Mike

This is very rude, you know.

In the last weeks we have had four discussions about hints.

You only mention 3 here ?

The first problem was a bug and is solved.

So .... ?

Isn't that both consistent and reasonable?

But why anybody should have any interest to develop a solution, if he read statements like: "Sending a patch to implement the missing feature that you want will increase the chance that it'll be added to FPC."

If you want the solution, implement it and donate back to the community. That's what open source is about.

Micha

Usually such a comment is enough for a filter to trash ...

So? Currently the chances might be zero, if somebody provides a good patch chance might be one. I call this an increase.

Hi Micha,

Micha wrote

> In the last weeks we have had four discussions about hints. You only mention 3 here ?

I count four. The first, the second, the third and the problem discussed in this thread.

> The first problem was a bug and is solved. So .... ?

If you have any interest to know it, take a look in the thread 'bool / boolean converting'.

wkr Peter.