Prog to find unused stuff in your source code..part 3

[Charles Dietz]

Borje,

I really like your pbcodec program. Found one error, though.
A global array is declared (outside the procs). It is dimensioned, but not used,
inside a subroutine. Your results erroneously report it as an unused local.

I wonder if unused equates and line labels could also be treated.


------------------

[Fred Oxenby]

Börje, Du har gjort ett fantastiskt jobb, hur hinner Du?
Jag har testat på ett av mina större projekt, och fann en
del oanvända funktioner. Då slog det mig. Kanske Du skulle
kolla om sub/funktioner kallas via codeptr?
-------
free Xlate
A really,really nice work.

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Borje Hagsten]

Charles, just tested and latest update seems to have fixed this. Had
a stupid bug in an earlier file, where even regular commands could
be counted as locals. Now fixed, I think.

Fred, as far as I can see, Codeptr and Call Dword calls are included
in reference count.

------------------

[Charles Dietz]

Borje, my probem is still there. But I'm beginning to think that even though
my code has worked for months, it was only because of PB compiler's leniency.
I re-read the PB documentation, and now realize that I should have used:

GLOBAL myArray() AS STRING

SUB mySub
DIM myArray(100) AS GLOBAL STRING

...rather than just: DIM myArray(100) without 'AS GLOBAL STRING'
After making that change, your code worked perfectly.


------------------

[Borje Hagsten]

This DIM xx AS GLOBAL -thing is actually very confusing. Can't understand
why it's been made possible at all. I mean, if to declare it in a routine,
variable/array becomes global to entire program, but if used in a routine
that preceeds the declaration, the compiler will protest. I can understand
why, but the logic is a bit odd. If to handle this properly, compiler should
scan entire code for all declares and then consider DIM AS GLOBAL accordingly.

Another thing, maybe a tick for the whishlist: I know variable names
means nothing once they are compiled, but still - like in above case:
it is possible to declare a global var and then use same "name" as
local in another place. Sometimes this can be very confusing and even
cause extremely hard-to-find bugs.

Next thing on the agenda is actually a "GLOBAL vs LOCAL" name reference
check, that can warn for this thing. I mean, it's possible to declare
a var as GLOBAL, then in routine declare same name as LOCAL, forget about
the local and later on, in same routine, set a value to what you think is
the global var, but in this routine is a local with identical name. The
"real" global has never been addressed..

Do this somewhere in a huge project like one I have here, 29 includes, many
100's of routines and miles of almost uncommented code. Then ask someone
else to find the error, while you go on a long vacation..

------------------
BTW, I think it should be like:

GLOBAL myArray() AS STRING

SUB mySub
  REDIM myArray(100)

[This message has been edited by Borje Hagsten (edited July 25, 2001).]

[Lance Edmonds]

Borje, that syntax is allowed. The "AS GLOBAL" portion is currently optional, but recommended for clarity (to avoid scope confusion).

If you have problems when omitting the "AS GLOBAL" clause, there must be some other issue in the code affecting the scope of the variable/array.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Trader]

How do you say this better:

IF (INSTR(1, LineStr, "LOCAL ") OR UnderScoreLastFlag) OR _ ' gotta be a better way to say this
(INSTR(1, LineStr, "LOCAL ") AND UnderScoreLastFlag) THEN

I want it true if both arguments are true OR if either argument is true
but NOT if both are false

------------------
Kind Regards
Mike

[This message has been edited by Mike Trader (edited July 25, 2001).]

[Borje Hagsten]

Hm, yes - like they say, "if it works, it must be correct".

However, in first case, PBcodec actually reported correctly. If
same name is used doth for Global and Local declare, variable is
Local in the routine where it was declared as Local and Global
everywhere else. If to set a value to it in "Local" routine, the
global version (same name) won't be addressed.

Same with arrays and "regular" variables, which is why I ranted
about dangerous mixes. Okay, so I'm having fun here - just added
first implementation of a "GLOBAL vs LOCAL WARNING" to the prog.

PBcodec now stores all local vars in a separate array and compares
this to all globals in the report. If same name has been used, the
name will be listed. Good idea to take notice of this warning.

I ran a test on several files here and immediately found several
possible bugs, like hEdit and hDlg being used as both Global and
Local in several files. Brr..

New file uploaded to http://www.tolken99.com/pb/pbcodec.zip
(..and in case someone doesn't understand what I mean, test this:

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
' Declares
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
#COMPILE EXE
#INCLUDE "WIN32API.INC"
 
GLOBAL hEdit AS LONG
DECLARE CALLBACK FUNCTION DlgProc() AS LONG
 
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
' Create dialog and controls, etc
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
FUNCTION PBMAIN () AS LONG
 LOCAL hDlg AS LONG, hEdit AS LONG
 
  DIALOG NEW 0, "Find the error..",,, 195, 50, %WS_CAPTION OR %WS_SYSMENU, 0 TO hDlg
  CONTROL ADD BUTTON, hDlg, %IDOK, "hEdit's value",   4,  4, 60, 14, %WS_TABSTOP
  hEdit = 55
 
  DIALOG SHOW MODAL hDlg CALL DlgProc
END FUNCTION
 
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
' Main callback
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
CALLBACK FUNCTION DlgProc() AS LONG
  IF CBMSG = %WM_COMMAND THEN
     IF CBCTL = %IDOK THEN
        MSGBOX "If no danger with mixed Local/Global, hEdit should be 55, but is: " & STR$(hEdit)
     END IF
  END IF
END FUNCTION

------------------

[Borje Hagsten]

Mike, simpliest form, if any one them returns a value:

IF INSTR(LineStr, "LOCAL ") OR UnderScoreLastFlag THEN

------------------

[Mike Trader]

Borge,

Yes but this evaluates as False if BOTH conditions are true
(or maybe im tired and my testing is off)

------------------
Kind Regards
Mike

[Russ Srole]

PBCodec is a great utility. My heartfelt thanks to all of you guys.

Borje, your comments about Global & Local variable having the same
name will make me lose sleep until I check and make sure I haven't
done that to myself. Perhaps an addition to PBCodec would be a
warning if it finds that sort of thing. I'll bet a lot of folks
will finally find that really obscure bug they've been searching for.

Russ Srole


------------------

[Russ Srole]

Borje,

As usual, you are way ahead. I just ran you latest & of course
it does flag the global/local variables. Thanks again.

Russ Srole

------------------

[David L Morris]

Great code example again Borje.

Am I correct in the belief that, while a function or sub is in an inc file, if
it is not referenced in the program, it is not compiled into the
exe?

For example, I included the old edit32.inc and List32.inc. Most
of the functions show as UN-USED after running PBcodec.

Have I bloated my compiled exe?

Regards,

David

------------------

[Eddy Van Esch]

Borje,
Your PBCodec reports my callback function CBF_ST_FUNNYCHECK in the line below as unused
although it is not.
The reason is (I'm 99% certain..) the single quotes in the checkbox text:
"Enable 'smart remarks'"
I guess your parser interpretes the single quotes as start of a comment..
I had the same bug in a parser I made myself..

CONTROL ADD CHECKBOX , hSettings&,  %ST_FUNNYCHECK, "Enable 'smart remarks'",10, 190, 100, 15, CALL CBF_ST_FUNNYCHECK

This bug occured in a few similar code lines so I'm pretty sure the
single quotes are the cause..
Kind regards
Eddy



------------------
[email protected]

[Lance Edmonds]

Topic closed due to excessive size. If more discussion is necessary (!) then please create a new Topic and include the URL of this topic.

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>