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
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 "Initializ
Am Friday 20 November 2009 09:42:16 schrieb Graeme Geldenhuys:
> Either way, my code is working now and is hint free.
I thought it is impossible, but you give me hope...
Rainer
>
>
> Regards,
> - Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.f
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 i
Graeme Geldenhuys schreef:
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 ...
Option #1:
--
procedure TForm.FormCreate(Sender: TObject);
b
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:
Graeme Geldenhuys wrote:
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.
So I have a solution, but I consider
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
de
Am Friday 20 November 2009 07:40:33 schrieb Graeme Geldenhuys:
> 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
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
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
On Thu, Nov 19, 2009 at 4:18 AM, Jonas Maebe wrote:
>
> On 19 Nov 2009, at 07:35, Graeme Geldenhuys wrote:
>
>> 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 und
Vinzent Höfler wrote:
Rainer Stratmann :
Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
{$HINTS OFF}
... code ...
{$HINTS DEFAULT}
maybe? Whereas DEFAULT restores the switch to the original state.
But then you have to do it everywhere in the code instead of on
Rainer Stratmann :
> Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
> >
> > {$HINTS OFF}
> >
> > ... code ...
> >
> > {$HINTS DEFAULT}
> >
> > maybe? Whereas DEFAULT restores the switch to the original state.
>
> But then you have to do it everywhere in the code instead of one time
Rainer Stratmann wrote:
Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
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
Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
> 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 DEFAUL
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.
Vinze
Jonas Maebe wrote:
On 19 Nov 2009, at 22:50, 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/h
On 19 Nov 2009, at 22:50, 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
Am Thursday 19 November 2009 22:40:53 schrieb Vinzent Höfler:
> 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< -
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
Graeme Geldenhuys :
> On 19/11/2009, 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.
Of course. The side-effect is much more in
Graeme Geldenhuys :
> 2009/11/19 "Vinzent Höfler" :
> >
> > Why don't you create your own initialization routine together with the
>
> 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.
I understand.
> If I
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > 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:
>
> And? Is there a different reason written? And even if it is:
> documentatio
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
init
On 19/11/2009, 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
2009/11/19 "Vinzent Höfler" :
>> 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
Be
On 19 Nov 2009, at 20:44, 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 s
W dniu 2009-11-19 20:29, Florian Klaempfl pisze:
Vinzent Höfler schrieb:
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:
And? Is there a different reason written? And even if it is:
documentatio
Vinzent Höfler schrieb:
> 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:
And? Is there a different reason written? And even if it is:
documentation writer know less than implementors :)
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
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 transparenc
Zaher Dirkey wrote:
>
> procedure ZeroMemory(Destination: Pointer; Length: DWORD);
> begin
> FillChar(Destination^, Length, 0);
> end;
Out of interest, I would recommend you change DWORD to PtrUInt. DWORD is
limited two a 32bit value on 64bit systems.
Regards,
- Graeme -
--
fpGUI Toolkit
In our previous episode, Florian Klaempfl said:
> > 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!
>
> If hin
Graeme Geldenhuys schrieb:
> 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 th
Graeme Geldenhuys schrieb:
> 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 writ
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
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
Graeme Geldenhuys schrieb:
> 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 wil
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-plat
On 19 Nov 2009, at 08:18, Jonas Maebe wrote:
On 19 Nov 2009, at 07:35, Graeme Geldenhuys wrote:
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.
On 19 Nov 2009, at 07:35, Graeme Geldenhuys wrote:
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.
It's not about it not being a high priority pr
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 -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
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,
Cox, Stuart TRAN:EX wrote:
>
> 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 o
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.
The original FillChar in FPC uses a 'var' parameter whic
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 declarati
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
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
mo
2009 9:15 AM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] How to solve "variable does not seem to be
initialized" compiler hint.
On Wed, Nov 18, 2009 at 17:58, Jonas Maebe wrote:
>
> What is the problem with fillchar? (other than that it prints a wrong hint in
>
On Wed, Nov 18, 2009 at 6:58 PM, 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 hi
On Wed, Nov 18, 2009 at 17:58, Jonas Maebe wrote:
>
> 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 situatio
On 18 Nov 2009, at 17:58, 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 e
On 18 Nov 2009, at 17:53, 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 betwe
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/li
On 18 Nov 2009, at 17:35, 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 conside
begin
{$PUSH}
{$HINTS OFF}
FillChar(x,count,Value);
{$POP}
end;
Shouldn't this code too raise a warning?
No, that's what the {$HINTS OFF} is used for - hiding the compiler hints
& warnings.
But isn't the warning raised when x is used as a parameter of a function? The
problem is, that fillcha
Flávio Etrusco wrote:
>> begin
>> {$PUSH}
>> {$HINTS OFF}
>> FillChar(x,count,Value);
>> {$POP}
>> end;
>>
>
> Shouldn't this code too raise a warning?
No, that's what the {$HINTS OFF} is used for - hiding the compiler hints
& warnings.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platf
On Tue, Nov 17, 2009 at 7:19 PM, JoshyFun wrote:
> 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 "fill
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 M
On 17 Nov 2009, at 20:47, 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
___
fpc-pascal maillist - fpc-pasc
>> 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 shou
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.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/
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
Hello, Graeme!
Tuesday, November 17, 2009, 2:20:18 PM, you wrote:
> 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.
Fantomas wrote:
>
> 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 y
Hello, Graeme!
Tuesday, November 17, 2009, 1:03:22 PM, 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/dcpblockc
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;
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 init
69 matches
Mail list logo
