Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
hint free [Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
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 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. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: hint free [Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
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); 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. For you as Lazarus user there is another option: Compiler options - Verbosity - uncheck Show hints for parameter Sender not used 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! 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: hint free [Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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. Out is not made to solve such problems but plainly to work with COM/Corba. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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. So we should disable OUT for anything but Windows? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 hints are really important, they would be warnings. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Graeme Geldenhuys gra...@mastermaths.co.za: [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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Florian Klaempfl flor...@freepascal.org: 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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Vinzent Höfler schrieb: Florian Klaempfl flor...@freepascal.org: 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 :) -- 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
W dniu 2009-11-19 20:29, Florian Klaempfl pisze: Vinzent Höfler schrieb: Florian Klaempflflor...@freepascal.org: 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 :) 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 safe to use with interfaces, ansistrings, dynamic arrays? Yes. Should I stop using it this way? No. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
2009/11/19 Vinzent Höfler jellyfish.softw...@gmx.net: 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 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
On 19/11/2009, Jonas Maebe jonas.ma...@elis.ugent.be 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. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Florian Klaempfl flor...@freepascal.org: Vinzent Höfler schrieb: Florian Klaempfl flor...@freepascal.org: 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 :) 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. -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Graeme Geldenhuys graemeg.li...@gmail.com: 2009/11/19 Vinzent Höfler jellyfish.softw...@gmx.net: 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 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. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Rainer Stratmann rainerstratm...@t-online.de: 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. -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
Am Thursday 19 November 2009 22:40:53 schrieb Vinzent Höfler: Rainer Stratmann rainerstratm...@t-online.de: 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. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 (e.g., 1234) c) use -vm1234 in the future to globally suppress this warning/note/hint Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
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/hint you want to suppress
(e.g., 1234)
c) use -vm1234 in the future to globally suppress this warning/note/hint
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
Martin f...@mfriebe.de:
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.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
Martin f...@mfriebe.de:
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
Rainer Stratmann wrote:
Am Thursday 19 November 2009 23:16:26 schrieb Vinzent Höfler:
Martin f...@mfriebe.de:
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.
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
Rainer Stratmann rainerstratm...@t-online.de:
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.
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.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: suppressing hints[Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.]
Vinzent Höfler wrote:
Rainer Stratmann rainerstratm...@t-online.de:
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.
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.
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
On Thu, Nov 19, 2009 at 4:18 AM, Jonas Maebe jonas.ma...@elis.ugent.be 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. 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 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 ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler 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 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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 fillchar is not considered to be an initialization of x. So
when using x it is still considered uninitialized.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
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 jonas.ma...@elis.ugent.be 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 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). 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). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
On Wed, Nov 18, 2009 at 6:58 PM, Jonas Maebe jonas.ma...@elis.ugent.be 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. -- Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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) -Original Message- From: fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Aleksa Todorovic Sent: Wednesday, November 18, 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 jonas.ma...@elis.ugent.be 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 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). 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). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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. 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). Or by adding support for a different parameter modifier to the compiler that has slightly different semantics than the current out modifier. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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! If hints are really important, they would be warnings. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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
--
Best regards,
JoshyFun
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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/dcpblockciphers.pas(229,16) Hint: Local variable Temp does not seem to be initialized 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; 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. -- Best regards, Fantomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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 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 - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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/fpc-pascal
Re: [fpc-pascal] How to solve variable does not seem to be initialized compiler hint.
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-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
