Hi,

And how do I solve this compiler hint? Normally I use FillChar(), but here it made no difference. The hint no simply moved to the line containing FillChar() call. :-(

/home/graemeg/programming/3rdParty/DCPcrypt/dcpblockciphers.pas(229,16) Hint: Local variable "Temp" does not seem to be initialized

-------------------------------
procedure TDCP_blockcipher64.DecryptCFB8bit(const Indata; var Outdata;
    Size: longword);
var
  i: longword;
  p1, p2: Pbyte;
  TempByte: byte;
  Temp: array[0..7] of byte;
begin
  if not fInitialized then
    raise EDCP_blockcipher.Create('Cipher not initialized');
  p1:= @Indata;
  p2:= @Outdata;
  FillChar(Temp, SizeOf(Temp), 0); // <-- I added this to no affect
  for i:= 1 to Size do
  begin
    TempByte:= p1^;
    EncryptECB(CV,Temp);          // <- original hint was here
    p2^:= p1^ xor Temp[0];
    Move(CV[1],CV[0],8-1);
    CV[7]:= TempByte;
    Inc(p1);
    Inc(p2);
  end;
end;
-------------------------------

Regards,
- Graeme -

Hello Graeme,

Tuesday, November 17, 2009, 11:03:22 AM, you wrote:

GG> /home/graemeg/programming/3rdParty/DCPcrypt/dcpblockciphers.pas(229,16)
GG> Hint: Local variable "Temp" does not seem to be initialized
[...]
GG>     raise EDCP_blockcipher.Create('Cipher not initialized');
GG>   p1:= @Indata;
GG>   p2:= @Outdata;

Insert this, or in other words "use it". The reason is that "fillchar" first parameter is "var" instead "out".

Temp[0]:=0;
GG>   FillChar(Temp, SizeOf(Temp), 0); // <-- I added this to no affect
GG>   for i:= 1 to Size do

Hello, Graeme!

you wrote

And how do I solve this compiler hint? Normally I use FillChar(), but here it made no difference. The hint no simply moved to the line containing FillChar() call. :-(

/home/graemeg/programming/3rdParty/DCPcrypt/dcpblockciphers.pas(229,16) Hint: Local variable "Temp" does not seem to be initialized

That compiler hint appears because you have not assigned a value to the variable Temp before passing it to a function as a parameter. You can pay no attention to that hint or switch off hints in your code where the hint is produced, if it really bothers you.

That you. I agree with JoshyFun though. It seems like it is actually a problem in the FillChar() definition and that should be fixed, instead of simply ignoring the hint.

I raised this issue in the fpc-devel mailing list.

Regards,
- Graeme -

Hello, Graeme!

In my humble opinion, there are no problems with the FillChar declaration. But the way you wrote your _absolutely correct_ code produced a hint. You shold use $HINTS OFF, for amendment to the FillChar declaration seems to be done unlikely.

In my humble opinion, there are no problems with the FillChar declaration. But the way you wrote your _absolutely correct_ code produced a hint. You shold use $HINTS OFF, for amendment to the FillChar declaration seems to be done unlikely.

But there is a reason for the hints. It should point you to possible problems (or optimitations). When switching it off, you also loose all other hints. That's not a solution, it's a workaround.

Can the Fill... functions be changed to have the first parameter "out" instead of "var" ? Surely they don't use it as an input parameter.

As far as I know $HINTS is a local directive. So, you can circumscribe only a certain piece of your code. E.g:

{$HINTS OFF}
FillChar(Temp,SizeOf(Temp),0);
{$HINTS ON}

You may consider my point to be a bit conservative, but I really do not think there is something to change about the FillChar declaration.

cobines wrote

Can the Fill... functions be changed to have the first parameter "out" instead of "var"

No: http://lists.freepascal.org/lists/fpc-devel/2009-November/018532.html

Jonas

Hello FPC-Pascal,

Tuesday, November 17, 2009, 8:47:03 PM, you wrote:

c> Can the Fill... functions be changed to have the first parameter "out" c> instead of "var" ? Surely they don't use it as an input parameter.

Write your own "fillchar" like function and inline it, something like:

procedure MyFillChar(out x; count: SizeInt; Value: char); inline;
begin
{$PUSH}
{$HINTS OFF}
  FillChar(x,count,Value);
{$POP}
end;

Shouldn't this code too raise a warning?

-Flávio

No, that's what the {$HINTS OFF} is used for - hiding the compiler hints & warnings.

Regards,
- Graeme -

But isn't the warning raised when x is used as a parameter of a function? The problem is, that fillchar is not considered to be an initialization of x. So when using x it is still considered uninitialized.

Jürgen Hestermann wrote

But isn't the warning raised when x is used as a parameter of a function? The problem is, that fillchar is not considered to be an initialization of x. So when using x it is still considered uninitialized.

a) a "var" parameter is considered as initialising a variable (although it also expects input to be initialised already) b) "Uninitialised" hints/warnings are only given once per variable (even regardless of whether the warning/hint is printed or not, as the state of the variable in the compiler will be changed so that it won't be printed anymore).

Jonas

Related to FillChar
In Delphi there is ZeroMemory, i guess it is windows API, can we have one in FreePascal to use it instead of FillChar.

Zaher Dirkey wrote

In Delphi there is ZeroMemory, i guess it is windows API, can we have one in FreePascal to use it instead of FillChar.

What is the problem with fillchar? (other than that it prints a wrong hint in some cases.

Also note that the difference between hints and warnings is exactly that hints are not guaranteed to be 100% correct or relevant in all situations; if they were, then they would be warnings. Hints are mainly intended to help you scrutinise your code more closely in case there's a problem you can't find, by flagging things that *might* indicate a problem. Getting all code hint free is probably not even possible (or desirable).

Jonas

Jonas Maebe wrote

Also note that the difference between hints and warnings is exactly that hints are not guaranteed to be 100% correct or relevant in all situations; if they were, then they would be warnings.

Or notes. In order of usefulness/accuracy, we have errors, warnings, notes and hints.

Jonas

You're completely right about that - there is nothing _wrong_ about fillchar. But if you have fillchar in, say, 20 places in your code, then you'll have to check all of those 20 places every time you build your project. And the idea of notices and hints is they are not to be ignored, but checked, isn't it? :-)

As of myself, I don't really care if there will be new safe_fillchar_with_no_hints function or not - it is easy to encapsulate fillchar, as JoshyFun pointed out. Aside from that, fillchar is unsafe by its nature, so having hint whenever one uses it is good idea (as a side effect of uninitialized variable in this case).

Jonas Maebe wrote

What is the problem with fillchar? (other than that it prints a wrong hint in some cases.

procedure ZeroMemory(Destination: Pointer; Length: DWORD);
begin
  FillChar(Destination^, Length, 0);
end;

There is no var in ZeroMemory so no hint i guess.

In all of this discussion, shouldn't the point be that the passing an un-initialized variable is correctly being reported as a possible error (of limited severity)?

The _proper_ solution is to initialize the variable's contents and then use it. The alternative is to substitute an alternative procedure, like, say, ZeroMemory or write a clever wrapper procedure.

One of the features of languages like Pascal is that one's warned of their oversights by the compiler. The alternative is blindingly visible in products like W-----$ and buffer overruns a-plenty in other apps compiled with a language from the hierarchy derived from a language between B and D.

Stu Cox (his own opinions)

In our previous episode, Cox, Stuart TRAN:EX said:

In all of this discussion, shouldn't the point be that the passing an un-initialized variable is correctly being reported as a possible error (of limited severity)?

The procedure in question is a typical initialisation. But because it is more library oriented, it pops up.

But I agree with Jonas. The problem is the obsession to eliminate each and every warning, not the hint/warning.

Hello FPC-Pascal,

Wednesday, November 18, 2009, 11:00:03 PM, you wrote:

MvdV> The procedure in question is a typical initialisation. But because it is MvdV> more library oriented, it pops up.
MvdV> But I agree with Jonas. The problem is the obsession to eliminate each and MvdV> every warning, not the hint/warning.

It is not an obsession, its a need... I really like the hints and warnings but I must "eliminate" them to "mark" the procedure as ok, or new hints will be oversight hidden by a lot of trees in the forrest ;)

For sure I also left some hints here and there :)

But I agree with Jonas. The problem is the obsession to eliminate each and every warning, not the hint/warning.

In general this is true. But in this particular case (fillchar) it should be easily possible to avoid the hint message. I am not sure why it is such a problem to change the declaration of fillchar to tell the compiler that it initializes the parameter. That would be a clean approach. Simply suggesting to disable hints is an awkward workaround and not very much Pascal-like.

The original FillChar in FPC uses a 'var' parameter which expects already initialized parameter. The "custom" FillChar that was suggested earlier, use a 'out' parameter, which doesn't expect initialized values because they are going to be initialized in the function with the out parameter.

Regards,
- Graeme -

The _proper_ solution is to initialize the variable's contents and then use it. The alternative is to substitute an alternative

That was the whole point about this thread. I used uninitialized varibles and the compiler correctly hinted about it. I then made use of FillChar to initialize those structure types, but then to my surprise the actual code I wrote to initialize thsoe variables were now the source of that hint!

I still don't think this is right and I still think FillChar must be changed to out, at least in 'objfpc' mode. The first parameter in FillChar gets initialized by FillChar, so NO hint must be given. That's the whole point of FillChar.

As I know the work-around is yet another wrapper function (which I have done), but the source of the problem still exists.

Somebody did once attempt to correct the var parameter to out parameter in FillChar, but got to many errors. Probably not a high priority issue, so the problem was simply swept under the rug.

As for the COM usage requirement (which I honestly believe is the minority use case in FPC). Then create a different FillChar -type procedure to handle those corner cases, or create a different procedure which allows structure types to be initialized without compiler hints.

Regards,
- Graeme -

Marco van de Voort wrote

But I agree with Jonas. The problem is the obsession to eliminate each and every warning, not the hint/warning.

I fully agree with JoshyFun. It's nothing to do with obsession. I you keep getting thousands of "useless" hints you will eventually start ignoring them, and that is probably the time you will miss a REAL hint or warning that pops up between those thousands of useless ones. I don't have the time to seek through all my 200,000+ lines of code looking for what is 'real' hints and what is 'fake' hints.

I don't see any problem in trying to write code with no hints & warnings. That's simply clean code!

Regards,
- Graeme -

Zaher Dirkey wrote

There is no var in ZeroMemory so no hint i guess.

I can confirm that indeed, no compiler hint is raised. I called the procedure as follows...

  ZeroMemory(@Buffer, SizeOf(Buffer));

Regards,
- Graeme -

It's not about it not being a high priority problem, it's about it being fundamentally unfixable (except by using a completely different kind of declaration, such as a pointer). Again, see the thread on this topic on fpc-devel: http://lists.freepascal.org/lists/fpc-devel/2009-November/018532.html

Jonas

Or by adding support for a different parameter modifier to the compiler that has slightly different semantics than the current "out" modifier.

Jonas

If hints are really important, they would be warnings.

Jonas Maebe wrote

It's not about it not being a high priority problem, it's about it being fundamentally unfixable (except by using a completely different

See my reply in fpc-devel mailing list.

Bottom line is, I don't think it's right for a project that prides itself as being cross-platform, to force everybody to some behaviour that is specific to Windows and even more specific to Windows + COM projects.

Windows+COM is the corner case project, and it should be handled differently and NOT be the default rule in FPC.

Regards,
- Graeme -

Florian Klaempfl wrote

If hints are really important, they would be warnings.

And working with a uninitialized data structure is a good thing? I think not. So, like everybody else, I manually initialise my data structures - and because of my efforts to write safer code, the compiler gives me a hint "variable does not seem to be initialized". The exact opposite of what I was trying to do. So that hint is useless, after I really did fix the potential problem in code. The problem is simply FillChar that uses the wrong parameter type - var instead of out.

And now Jonas says the problem cannot be fixed simply because of the select few developers working on Windows+COM projects. The the problem must now be accepted by all because of a VERY specific use-case. That doesn't sound very "cross platform" to me??

Regards,
- Graeme -

Out is not made to solve such problems but plainly to work with COM/Corba.

So we should disable OUT for anything but Windows?

Hello Graeme,

Thursday, November 19, 2009, 8:52:41 AM, you wrote:

GG> And working with a uninitialized data structure is a good thing? I think GG> not. So, like everybody else, I manually initialise my data structures - GG> and because of my efforts to write safer code, the compiler gives me a GG> hint "variable does not seem to be initialized". The exact opposite of GG> what I was trying to do. So that hint is useless, after I really did fix GG> the potential problem in code. The problem is simply FillChar that uses GG> the wrong parameter type - var instead of out.

Its for sure that this discussion will end up in a dead point, things should be different ? Maybe yes. Will it be changed ? No to avoid problems. So as the compiler will issue hints about uninitialized data and FillChar is not the right procedure to initialize nothing except maybe a short string (due its name), why not create some procedures to initialize arrays and memory blocks with a more 21th century names ? Something like "InitializeArray" and "InitializeRecord". Would it require compiler magic ?

From my point of view FillChar name does not match a initialize data function. FillMemory (in wininc) is more clear but also it does not "initialize" a string.

GG> And now Jonas says the problem cannot be fixed simply because of the GG> select few developers working on Windows+COM projects. The the problem GG> must now be accepted by all because of a VERY specific use-case. That GG> doesn't sound very "cross platform" to me??

out parameters seems to have a "difficult to predict" effects on some types, I think interfaces could be affected by out parameters also and anything that it's auto-freed by the compiler.

In our previous episode, Florian Klaempfl said:

More importantly, if you really need the hints, you don't want that all important "real" hint being obscured by some obfuscation. You'd want the raw data, all of it.

Out of interest, I would recommend you change DWORD to PtrUInt. DWORD is limited two a 32bit value on 64bit systems.

Regards,
- Graeme -

Graeme Geldenhuys :

[FillChar]

As for the COM usage requirement (which I honestly believe is the minority use case in FPC).

AFAIK, the different semantic of "out" parameters applies to all reference counted types. That's especially unfortunate with dynamic arrays, where you lose transparency, because static and dynamic arrays behave differently under such circumstances.

Then create a different FillChar -type procedure to handle those corner cases, or create a different procedure which allows structure types to be initialized without compiler hints.

Why don't you create your own initialization routine together with the type? I often did this, especially because zeroing out some structure may help in having deterministic values in the fields, but I'd debate the general "initialization equals setting it to zero" approach (which I personally refer to as "paranoia initialization" - in practice it merely hides the bugs than to avoid them).

As a simple and stupid example: The code around an expression "a/b" remains wrong, no matter if "b" has been "initialized" to zero or contains some random "unitialized" value.

If there are range types involved, the so-called initialized value may even be invalid, because the 0 is not necessarily inside the defined range.

Vinzent.

Florian Klaempfl :

Out is not made to solve such problems but plainly to work with COM/Corba.

Really? Well, that's not what the FPC manual says:

-- 8< --
The purpose of an out parameter is to pass values back to the calling routine: The variable is passed by reference. The initial value of the parameter on function entry is discarded, and should not be used.

If a variable must be used to pass a value to a function and retrieve data from the function, then a variable parameter must be used. If only a value must be retrieved, a out parameter can be used. -- 8< --

So having the semantic difference between "var" and "out" and thus the differentiation between uninitialized and (pre)initialized parameters is merely a random achievement?

Vinzent.

And? Is there a different reason written? And even if it is: documentation writer know less than implementors :)

W dniu 2009-11-19 20:29, Florian Klaempfl pisze:

Is it wrong to use "out" for the sole purpose of informing the compiler that a function will set the initial value of a variable passed as the parameter? Or is it just a side effect? I use it all over the place in my programs. Is it safe to use with interfaces, ansistrings, dynamic arrays? Should I stop using it this way?

cobines wrote

Is it wrong to use "out" for the sole purpose of informing the compiler that a function will set the initial value of a variable passed as the parameter?

No.

Or is it just a side effect?

Yes.

I use it all over the place in my programs. Is it safe to use with interfaces, ansistrings, dynamic arrays?

Yes.

Should I stop using it this way?

No.

Jonas

2009/11/19 "Vinzent Höfler" :

Because not all the code I maintain is my own. Some code, as in the case of DCPCrypt gave stacks of hints which were all false positives. If I now go around changing all these pieces of code, it will make it harder to backport my actual fixes to the upstream DCPCrypt code.

DCPCrypt will be riddled with changes simply to stop FPC making such a lot of noize at compile time - and those changes will not actually be "fixes" for upstream repository.

the general "initialization equals setting it to zero" approach (which I personally refer to as "paranoia initialization" - in practice it

A simple example where it is vital to initialize such structures. I'm working on a IPF compiler (fpGUI + OS/2 help system compiler). It use a ton of data structures right down to bit level. If those data structures are not zero'ed out at initialization, this could have disastrous effects further down the line when random data still occupies those data structures.

So no, initializing data structures is nothing about "paranoia". It's about knowing what the initial value is of a type or data structure when it gets used.

Jonas Maebe wrote

> Or is it just a side effect? Yes.

Well it seems the "side effect" is more popular use-case in FPC and Delphi developers projects than the original intention of "out" then.

BTW:
I searched the Kylix and Delphi source folders. The "side effect" is used in 99% of all FillChar() cases. So that "side effect" is damn popular.
:-)

For me a variable is initialised when it passes a procedure/function which has a var declaration in the parameters.
May be it is possible to make a compiler switch like $PASS_VAR_NO_HINT ON
instead of globally
$HINTS OFF

Then all variables wich passes for example the fillchar procedure are initialised if the switch $PASS_VAR_NO_HINT ON is set.

Rainer

Florian Klaempfl :

That may be true. But here at work it wouldn't count, here we have to fit the program to the documentation, not vice versa. :)

Vinzent.

Graeme Geldenhuys :

I understand.

If I now go around changing all these pieces of code, it will make it harder to backport my actual fixes to the upstream DCPCrypt code.

Sure, especially with crypto code where proper initialization might even be the wrong thing: http://digitaloffense.net/tools/debian-openssl/

;)

> the general "initialization equals setting it to zero" approach (which > I personally refer to as "paranoia initialization" - in practice it A simple example where it is vital to initialize such structures.

[...]

Of course, you should (almost) never use uninitialized data. I didn't say that, did I?

So no, initializing data structures is nothing about "paranoia". It's about knowing what the initial value is of a type or data structure when it gets used.

There's a fine line between "initializing data before first use" and "initializing data when declared (or as close to the declaration as possible)".

Most people do the latter when they encounter the rule "all data must be initialized before use", because it's easier, involuntarily introducing bugs. Initialized data is no good when it still contains the wrong value.

And to give a rather extreme (reconstructed real-world) example of what I meant, doing

-- 8< --
var
   i : Integer; // Loop counter
begin
   i := 0;
   for i := 1 to ...
end;
-- 8< --

really *is* pure paranoia.

Vinzent.

Graeme Geldenhuys :

Of course. The side-effect is much more intuitive than the feature that created it. ;)

Vinzent.

Rainer Stratmann :

For me a variable is initialised when it passes a procedure/function which has a var declaration in the parameters.

-- 8< --
procedure Add_2 (var I : Integer);
begin
   I := I + 2;
end;
-- 8< --

If the variable for the parameter I wasn't correctly initialized before, it would still contain garbage upon return.

Vinzent.

Yes, but for that is the compiler-switch $PASS_VAR_NO_HINT ON. Then no hint is put out by the compiler.
If this switch is on the programmer is resposible for initialising variables which pass a function.

If someone doesn't find it useful then he/she is not forced to use the switch.

I would use this switch if it exists. My code is full of this passing variables through procedures/functions. And also I wonder of this many hints.

Rainer

Vinzent.

Rainer Stratmann wrote

Yes, but for that is the compiler-switch $PASS_VAR_NO_HINT ON. Then no hint is put out by the compiler.

When using FPC 2.4.0rc1 or later:
a) compile your code with -vq
b) note the message number for the warning/note/hint you want to suppress (e.g., 1234) c) use -vm1234 in the future to globally suppress this warning/note/hint

Jonas

Ideally it would be, if there was a directive or similar, to suppress it for given lines (or statements).
one that is easier than {$push} { $HINT OFF} ... {$POP}

As mentioned earlier on this thread: If a hint occurs you have to (or may want to) check it's valid => but only *once*

If you found the code ok and the hint to be a false positive, then you want to suppress this hint at the checked location. (if you later edit the code, you either check again before compiling or remove the suppress marker)

I know marcros are replaced recursively => do directives in macros work? => if so you could enclose the block with 2 short-named macros.

Then again this doesn't work for 3rd party code, that you don't want to modify => but usually you compile that once, and use the ppu (do ppu emit hints?)

Martin

Martin :

Ideally it would be, if there was a directive or similar, to suppress it for given lines (or statements). one that is easier than {$push} { $HINT OFF} ... {$POP}

{$HINTS OFF}

... code ...

{$HINTS DEFAULT}

maybe? Whereas DEFAULT restores the switch to the original state.

Vinzent.

But then you have to do it everywhere in the code instead of one time.

Rainer

That's the idea of hints. Telling you you need to look at the code once, and if it's ok => good. But if the hint was correct => fix it.

This was in reply to

use -vm1234 in the future to globally suppress this warning/note/hint

which would suppress *all* hints of the "uninitialized" type. => Which means you may lose possible valuable hints.
It defeats the idea of hints to turn them off globally (even if only specific hints).
You need to turn them off locally only.

This does not solve (but did not reply to neither) the case where if a hint for FillChar is generated, this hint is always wrong. (hence I changed the subject)

Martin

Rainer Stratmann :

Yes, that was the point. I want to disable only those hints which are proven to be bogus. Disabling the globally can be done easier with the message suppressing feature of the upcoming FPC release.

Vinzent.

So then the question is, if those macros will work (could be defined in an include file):

{$DEFINE HintOff = {$PUSH}{$HINT OFF} }
{$DEFINE HintDef = {$POP}}
  HintOff
  a:= b_is_not_initialized;
  HintDef

Out of curiosity, does anybody know how Delphi solves this? I don't remember seeing a warning (having to initialize variables) on FillChar in Delphi...

Best regards,
Flávio

PS. And of course, please disregard my previous comment on this thread ;-)

Rainer Stratmann wrote

May be it is possible to make a compiler switch like $PASS_VAR_NO_HINT ON

No. My issue is not the hint in general. The hint is if for "real" issues. My issue is that I tried to solve the compiler hint by manually initializing my structured types using FillChar(). And it return the hint did not go away, it simply moved location to the call to FillChar().

This was not what I expected. FillChar() is very often used to initialize structured types and arrays, so I did not expect the FillChar() to give me that same compiler hint. At closes inspection, I noticed the issue with FillChar - the first var parameter that should have been a out parameter.

Regards,
- Graeme -

Flávio Etrusco wrote

Out of curiosity, does anybody know how Delphi solves this? I don't remember seeing a warning (having to initialize variables) on FillChar in Delphi...

I tried the same thing last night with Kylix 3. It seems Kylix (and probably Delphi) doesn't even have such a hint to start with. Kylix never reported the hint FPC does.

That obviously doesn't mean Kylix & Delphi fixed the issue - it might simply mean that FPC has more hints & warnings support than what Kylix & Delphi does.

Regards,
- Graeme -

But how do you solve the hints where a variable is initialised by a function call with a var in the parameters then?

May be it is possible to print hints and warnings in different colours in the output screen. Then it is more userfriendly.

Rainer

Rainer Stratmann wrote

But how do you solve the hints where a variable is initialised by a function call with a var in the parameters then?

:-) That the exact problem I have and the reason for this message thread.

In the due, I had to create a local work-around due to the fact that FPC developers are not willing to fix/change the FPC FillChar() procedure.

I created a local dcpFillChar() which uses a out parameter. Inside the implementation of dcpFillChar() I enabled {$HINTS OFF}, and then called FPC's FillChar().

So for all structure that I do initialize, I have to use dcpFillChar(). If I forgot to initialize a typed structure before I use it, FPC will still give me the Hint output. At which point I can find the location of the offending code, and insert my call to dcpFillChar().

So I have a solution, but I consider it more a work-around that a 100% solution. :-( Either way, my code is working now and is hint free. Important thing is that if a Hint does pop up, I only need to inspect it once and solve the problem. The FPC will not complain about that code again.

Regards,
- Graeme -

....

"my code is working now and is hint free" => Wow.

Out of interest (because I have no idea how to (reasonable) archive that. The most common hint in 99% of all my apps is the "Parameter Sender (or whatever) not used in ...".

If you use events you can not remove the parameters from your procedure declarations, so you get that hint...; Not that it bothers me, but if you got an easy solution...

Martin

Martin wrote

If you use events you can not remove the parameters from your procedure declarations, so you get that hint...; Not that it bothers me, but if you got an easy solution...

Another very annoying hint! :-) Solution - apply yet more workarounds. FPC sure is verbal!

Option #1:
----------
  procedure TForm.FormCreate(Sender: TObject);
  begin
    Assert(Sender  nil); // or Sender = Sender or ....
    ... your normal code here...
  end;

Asserts are not enabled by default in Lazarus IDE projects, so that shouldn't generate any code, but it does shut the FPC compiler up from hinting like crazy.

Option #2:
----------
If you are using FPC 2.4.0-rc1 or later, then you can disable specific compiler messages. "Project > Compiler Options > Messages tab". Then simply uncheck the messages you do not want. "Parameter not used" is just about always unchecked in my projects.

On only if Lazarus IDE support a "Save current settings as default for new projects", that would have been great! Then we don't have to change these settings for each and every project. Icons, manifest files, .rc files etc in Project Options is another BIG annoyance for me.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Another very annoying hint! :-) Solution - apply yet more workarounds. FPC sure is verbal!

It is Friday again: To show that you are looking for problems with more than enough solutions ...

For you as Lazarus user there is another option:
Compiler options -> Verbosity -> uncheck Show hints for parameter "Sender" not used

For this problem you can add the relevant option in your fpc.cfg. Use show compiler options to see what the relevant -vm option is.

Vincent

Graeme Geldenhuys wrote

Either way, my code is working now and is hint free.

I thought it is impossible, but you give me hope... Rainer

Regards, - Graeme -

Vincent Snijders wrote

For you as Lazarus user there is another option: Compiler options -> Verbosity -> uncheck Show hints for parameter "Sender" not used

Thanks Vincent, I did not know about this option. I guess it's type I work my way through all the dialogs in Lazarus IDE to see what is new.

For this problem you can add the relevant option in your fpc.cfg. Use show compiler options to see what the relevant -vm option is.

Clever idea. I never thought about that.

Regards,
- Graeme -

Hello Graeme,

Friday, November 20, 2009, 9:42:16 AM, you wrote:

GG> I created a local dcpFillChar() which uses a out parameter. Inside the GG> implementation of dcpFillChar() I enabled {$HINTS OFF}, and then called GG> FPC's FillChar().

I had not tested it but you can create a general "Initializers.pas" unit, which redefine FillChar and maybe some others like "Move", them add the unit in the last position in your 3rd party unit and compile. If everything is hint free, you can remove the unit and add a hints off.

That's the idea of hints. Telling you you need to look at the code once, and if it's ok => good. But if the hint was correct => fix it.

But if you later change your code it may become not ok again. I don't think that this is good working practice. I would prefer to have the compiler recognize that fillchar *is* an initialization of a variable. That would solve the issue for all times and under all circumstances. No need for workarounds.