Code: Select all
Global Test.s
ProcedureDLL.s Dummy()
Protected Buffer.s = "bug"
Test = Buffer
ProcedureReturn Test
EndProcedure
nco2k
Code: Select all
Global Test.s
ProcedureDLL.s Dummy()
Protected Buffer.s = "bug"
Test = Buffer
ProcedureReturn Test
EndProcedure
No. Thanks for your helpnco2k wrote:does this work?
Code: Select all
ProcedureDLL.s Dummy()
Protected Buffer.s = "bug"
ProcedureReturn Buffer
EndProcedure
Debug "no " + Dummy()
Debug wrote:no bug
Nice then ^^falsam wrote: @Lunasole : That's a very good idea. But it's already coded. You will not get your tracking ticket
And that's really interesting. Played with it a bit I can't say WTF it happens, here is just comparison of assembly generated for 2 variants:falsam wrote:I need your help.
I create a userlib with this codeCode: Select all
ProcedureDLL.s Dummy()...
Code: Select all
; here no is missing from result
Define C$ = "no" + Dummy()
Code: Select all
; here all is OK
Define C$ = "no"
C$ + Dummy()
Code: Select all
PUSH dword [_PB_StringBasePosition]
MOV edx,_S1
PUSH edx
CALL _SYS_CopyString@4
MOV edx,[_PB_StringBasePosition]
PUSH edx
PUSH edx
CALL PB_Dummy
POP eax
PUSH dword v_C$
CALL _SYS_AllocateString4@8
Code: Select all
MOV edx,_S1
LEA ecx,[v_C$]
CALL SYS_FastAllocateStringFree
MOV edx,dword [v_C$]
PUSH dword [_PB_StringBasePosition]
PUSH edx
CALL _SYS_CopyString@4
MOV edx,[_PB_StringBasePosition]
PUSH edx
PUSH edx
CALL PB_Dummy
POP eax
PUSH dword v_C$
CALL _SYS_AllocateString4@8
Code: Select all
Define c$= "no"+Dummy()
Debug c$
Code: Select all
; Define c$= "no"+Dummy()
PUSH dword [_PB_StringBasePosition]
MOV edx,_S1
PUSH edx
CALL _SYS_CopyString@4
MOV edx,[_PB_StringBasePosition]
PUSH edx
PUSH edx
CALL PB_Dummy
POP eax
PUSH dword v_c$
CALL _SYS_AllocateString4@8
Code: Select all
Procedure.s dummy2()
Protected Buffer.s = "bug"
ProcedureReturn Buffer
EndProcedure
Define c$= "no"+Dummy2()
Debug c$
Code: Select all
;; Define c$= "no"+Dummy2()
PUSH dword [_PB_StringBasePosition]
MOV edx,_S2
PUSH edx
CALL _SYS_CopyString@4
PUSH dword [_PB_StringBasePosition]
CALL _Procedure0
POP eax
ADD dword [_PB_StringBasePosition],2
PUSH dword v_c$
CALL _SYS_AllocateString4@8
Code: Select all
Define Result$ = Dummy()
Debug "no " + Result$
Code: Select all
Debug "no " + Dummy()
Debug wrote:no bug
Does tailbite generate a asm-output?falsam wrote:The code being simple, I was able to create the library with Tailbite.
YesGPI wrote:Does tailbite generate a asm-output?
Code: Select all
_EndProcedure1:
PUSH dword [esp]
CALL _SYS_FreeString@4
ADD esp,4
RET + 4
Code: Select all
_EndProcedure1:
PUSH dword [esp]
CALL _SYS_FreeString@4
ADD esp,4
RET
I google it: It means, that you return and remove 4 Bytes from the stack.falsam wrote:If I change this last line, the debug gives the right result. But I don't know what RET + 4 means.
Possible. Ok, i don't understand x86-Assembler, but I understand c64 and Atari-ST-Assembler and know how things work there. A change from "RET" to "RET +4" is not a simple or small error. It is a huge error. It will cause a corrupt stack and this is reallly bad and maybe one of the difficult to find errors. I personal y think, that when it is a bug, it has crash a long time before this.falsam wrote: But i think there is a bug with pbcompiler. exe option /COMMENTED (Version x86)
Code: Select all
Case "i", "l"
ProcedureType = "Long | StdCall"
Yes, of course! You seriously think I'd get into this project without reading the documentation ?GPI wrote:Have you read the readme in the SDK-folder?
If the user uses a variable that is not compatible with the compiler, MLF will not fix it.GPI wrote:Also you handle Integers complete wrong.
Code:
Case "i", "l"
ProcedureType = "Long | StdCall"
on a x86 system this is correct, but under x64 an integer is a quad!
Alert !! MLF is very dangerousGPI wrote:At the current state, i would say, that MLF is a very early alpha stage. With a high risk of bugs. Don't use it in productive systems.
No problem: Beginner Forum !!GPI wrote:And maybe this thread should be moved to a different forum.
that is the problem. You must change the code or at least understand, what in the asm file. "Only put some public" will not lead to a function MLF. See the string problem (i don't think it is a PB bug, compare the code with and without userlibrary. The code of the dummy-procedure is always the same. The different is the "main-routine". It handles the call of the PB-Procedure different from the call of a Userlib-Procedure. And this why this bug happend. To solve this problem, you must understand, whats going on. Thats why it is important to lern Assembler, when your Project MLF should be a success. Otherwise you will never understand, why the "no" vanished or why the use of array will crash. Only then you could find solutions.falsam wrote:■ Concerning the ASM file
The only transformations are to make the procedures public. I would never change the assembler code.
btw. this is your code - you always translate integer to long in MLF. That is wrong. On x64 integer it is quad.GPI wrote:Code:
Case "i", "l"
ProcedureType = "Long | StdCall"
Maybe it sounds harder then it should - my english and my social skills are badYou say "MLF is a very early alpha stage" Yes, I agree with that. This is the first sentence of the first message. But he didn't deserve this bashing ....