64 bit assembler > UASM Assembler Development

OPTION LITERALS in 32 bits

(1/11) > >>

aw27:
It appears that OPTION LITERALS does not work properly in 32 bits.
In the code below if I remove the semicolon from "USELITERALS equ 1" the problems start. Strings are accepted in RtlInitAnsiString  but produce garbage. printf does not accept the literal.


--- Code: ---.386

;USELITERALS equ 1

.model Flat, C
option Casemap :None
IFDEF USELITERALS
OPTION LITERALS:ON ; Allow string literals use in INVOKE
ENDIF

TRUE equ 1

includelib \masm32\lib\ntdll.lib
RtlCompareString PROTO STDCALL :ptr,:ptr,:BYTE
RtlInitAnsiString PROTO STDCALL :ptr, :ptr

includelib \masm32\lib\msvcrt.lib
printf PROTO :PTR, :vararg

includelib \masm32\lib\kernel32.lib
ExitProcess proto STDCALL :dword

_STRING struct
_Length word ?
_Maximumlength word ?
_Buffer dword ?
_STRING ends

.data
format db 'result: %d',13,10,0
s1 db "someStr",0 ;
s2 db "anotherStr",0 ;

.code

main proc
LOCAL str1 : _STRING
LOCAL str2 : _STRING
IFDEF USELITERALS
INVOKE RtlInitAnsiString, addr str1, "someStr"
INVOKE RtlInitAnsiString, addr str2, "anotherStr"
INVOKE RtlCompareString, addr str1, addr str2, TRUE
INVOKE printf, "result: %d", eax
ELSE
INVOKE RtlInitAnsiString, addr str1, addr s1
INVOKE RtlInitAnsiString, addr str2, addr s2
INVOKE RtlCompareString, addr str1, addr str2, TRUE
INVOKE printf, addr format, eax
ENDIF

INVOKE ExitProcess,0

main endp

end main

--- End code ---

aw27:
But if I define the prototype of printf as "printf PROTO :PTR, :PTR" it works.
In this case the variation:
      INVOKE RtlInitAnsiString, addr str1, "someStr"
      INVOKE RtlInitAnsiString, addr str2, "anotherStr"
      INVOKE RtlCompareString, addr str1, addr str2, TRUE      
      INVOKE printf, "result: %d", eax
will work.
But this will not:
      INVOKE RtlInitAnsiString, addr str1, "someStr"
      INVOKE RtlInitAnsiString, addr str2, "anotherStr"
      INVOKE RtlCompareString, addr str1, addr str2, TRUE      
      INVOKE printf, addr format, eax

That is, we will be forced to use always literals on INVOKE.
So, it appears there are 2 problems:
1) Once you use literals on one parameter it expects ptr arguments on the following parameters.
2) You can not decide when to use literals or not once you subscribe the LITERALS option.

habran:
Hi aw27 :biggrin:
That is interesting find you've got there :shock:
At the moment I am busy with the SWITCH-CASE-ENDSWITCH and Johnsa is still on holidays, if he doesn't return soon I'll look at that issue as soon as I finish that new stuff that I am working on.
The fix will be included in next release together with the new stuff as soon as Johnsa returns.

aw27:
No worries, fortunately the default alternative OPTION LITERALS:OFF  works well :t

johnsa:
Hey,

(Still on holiday.. sort of) :)

The decision for string literals to only work with type PTR was intentional.. There was a lot of code where one might find something like this:

aFunction PROTO :DWORD

which was being called with

invoke aFunction, "abcd"

Technically string immediates were already supported as long as it fitted in the corresponding type, "A", "AB", "ABCD" etc.. So to avoid a) confusion and b) breaking existing code I used a combination that would
never have existed previously, no one would have a called a function with a type declared as PTR with a string/character immediate value.

As for the other issues that shouldn't happen and I will investigate if Habran doesn't beat me to it :)

Navigation

[0] Message Index

[#] Next page

Go to full version