Page 2 of 4
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 5:54 pm
by TI-994A
NicTheQuick wrote:There should be absolute no difference between using Str() directly or first store its return value in a variable.
The persistence of the temporary memory location where the results of the
Str() function is stored makes the difference.
Saki wrote:...something is overwritten...
Most likely, because the temporary memory location where the results of the
Str() function is stored is not preserved.
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 6:02 pm
by mk-soft
Replace for testing the function "GetCursor_Y_FW()".
Perhaps problem with internal registers ...
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 6:33 pm
by Saki
Simplificated
(Also frames removed)
The created value box height is : $10205782D - This no longer fits on my desktop
The correct box height is $2D

This is probably not a coincidence.
Interesting - So you can already see what happens, but where he gets these bytes is a mystery to me.


Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 7:09 pm
by NicTheQuick
If you change the height to other values, will it result in the same correlation?
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 7:24 pm
by Saki
I change the height to $DD
The low byte is now $DD
The other bytes change immediately, it looks too adresses :
sample $10388C0DD // $10385ACDD // $1060968DD
I change to $DDAA so i get as sample $1068B3BAA
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 7:37 pm
by NicTheQuick
What is the exact definition of the procedure DrawText_FW. Are all the parameters either integer or strings? Or are there also some bytes, words or similar?
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 7:51 pm
by Paul
You say this only happens in large projects and cannot be reproduced with small snippets. Unfortunately without supplying a large chunk of code that reproduces this problem it is quite hard for anyone to suggest where the issue may be coming from, whether it be a compiler bug or caused by your own code somewhere.
It is quite possible there is corruption caused by other parts of your program.
For example if you look at code you have written in GFX_Wizard, you use GOTO quite a bit to exit loops in some of your procedures, when it is specifically stated in the help file not to do this.
Just something to watch for if you continue this practice

Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 8:13 pm
by Olli
If you create a user function named
St() like this :
Code: Select all
Procedure.S St(Q.Q)
ProcedureReturn Str(Q)
EndProcedure
... And you replace Str() with St(), does it crash ?
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 8:23 pm
by Saki
Hi Nick, look the Declare Part
Code: Select all
Declare DrawText_FW(output_ID,
Font$,
font_flag,
output_x,
output_y,
output_width,
output_height,
text_color=#Black,
text_adjustment=0,
background_color=-1,
text$=" ",
padding_x=0,
padding_y=0,
resize_factor.f=1)
No, I don't use word, long or byte in the whole FontWizzard.
I also don't work here with pointers.
It is a very simple code.
Hi Paul,
no in the FontWizzard not a single goto is used.
In the whole GFX_Wizzard_BF 11 Goto are used with over 26 000 lines.
10 of these goto jump to error:
All for and inside the Progressbar_BF Procedure, this is a very complex function.
This procedure can create and remove coloured custom progressbars based on the PB progressbars.
When removing, everything is cleaned up and the function is then exited.
If an error occurs in the function, it simply jumps to this part at the end of the procedure, that's all.
A macro would do the same, but it bloats the code.
A separate procedure for this would have to be given all the necessary local parameters again,
without any further benefit, just ballast.
The remaining one Goto only repeats two very little nested for next loop.
It is simply a simple solution, which I could not solve otherwise by far so elegantly, not more.
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 9:00 pm
by ProphetOfDoom
TI-994A wrote:Nevertheless, it's usually not good coding practice to pass functions as parameters to other functions.
Oh my! I don’t know where to begin. In Haskell, entire programs are glued together by higher-order functions. Gtk uses callbacks for every signal. This just such a vastly useful thing in a programmer’s toolkit!
WRT the bizarre memory corruption bug... I honestly would suspect something to do with malloc/free or related functions. An invalid free() or a use-after-free often causes strange behaviour that only manifests elsewhere in the program or at some completely unrelated time. They are some of the worst and most insidious bugs... almost as bad as multi threading bugs which are often a nightmare.
Unfortunately due to PureBasic’s proprietary nature and PB programs’ weird behaviour under debuggers it’s impossible to run a memory checker like valgrind which can find these kinds of problems. (At least, I’ve never been able to do this).
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 9:13 pm
by Saki
Hi Olli
at the same, creating a sub function help not
Hi ProphetOfDoom
Yes you are right
Yes, it can be what it wants, but it is certainly not due to a programming mistake.
The whole FontWizzard is based on the merging of simple PB functions.
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 9:34 pm
by skywalk
Saki - You really need to use EnableExplicit. And if Strings are your downfall, remove them from your critical code. Replace them with byte arrays.
Not the be all end all of coding rules, but NASA's list does not explicitly rule out function calls within parameters.
Code: Select all
NASA’s 10 Rules:
1. Restrict all code to very simple control flow constructs—do not
use goto statements, setjmp or longjmp constructs, or direct or
indirect recursion.
2. Give all loops a fixed upper bound.
3. Do not use dynamic memory allocation after initialization.
4. No function should be longer than what can be printed on a
single sheet of paper in a standard format with one line per
statement and one line per declaration.
5. The code's assertion density should average to minimally two
assertions per function.
6. Declare all data objects at the smallest possible level of scope.
7. Each calling function must check the return value of nonvoid
functions, and each called function must check the validity of all
parameters provided by the caller.
8. The use of the preprocessor must be limited to the inclusion of
header files and simple macro definitions.
9. Limit pointer use to a single dereference, and do not use
function pointers.
10. Compile with all possible warnings active; all warnings should
then be addressed before release of the software.
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 9:51 pm
by Saki
Hi Skywalk,
yes, of course you are right.
But there is and was not a single code of mine without EnableExplicit().
I only started this thread because I wanted to make others aware of this and because I am very interested in the cause.
Maybe someone can clear it up.
I would have liked to make a small neutral code, but unfortunately I did not succeed.
It would be nice and useful for all if we could clear up this mystery.
Look, this is the begin from the FontWizzard_BF Module, the first three lines :
Code: Select all
; FontWizzard_BF
DeclareModule FontWizzard_BF
EnableExplicit
This is the begin of the little demo code above, the first three lines :
Code: Select all
; FontWizzard_BF - Demo code - Formatted lists
XIncludeFile("./FontWizzard_BF.pbi")
EnableExplicit
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 11:07 pm
by Tenaja
Paul wrote:
Just something to watch for if you continue this practice

That's a nice way of saying "if you intentionally program bugs into your code, don't blame the compiler."
Re: The unknown dangerous Procedure StringFunction Bug
Posted: Sun Feb 14, 2021 11:10 pm
by Saki
Hi Tenaja,
show me the mistake I made.
The localisation of programming errors is always based on facts, not on assumptions.
No offence, but you can't judge my codes negatively without knowing them.