Why only unsigned number ?
There is just a very few lines to add for signed or unsigned Numbers.
Example:satodw
; #########################################################################
satodw proc String:DWORD
local moins:DWORD
; ----------------------------------------
; Convert decimal string signed or unsigned into dword value
; return value in eax
; ----------------------------------------
push esi
push edi
xor eax, eax
mov moins,0
mov esi, String
.if byte ptr [esi] == "-" || byte ptr [esi] == "+"
.if byte ptr [esi] == "-"
inc esi
mov moins,1
.else
inc esi
.endif
.endif
xor ecx, ecx
xor edx, edx
mov al, [esi]
inc esi
cmp al, 2D
jne proceed
mov al, byte ptr [esi]
not edx
inc esi
jmp proceed
@@:
sub al, 30h
lea ecx, dword ptr [ecx+4*ecx]
lea ecx, dword ptr [eax+2*ecx]
mov al, byte ptr [esi]
inc esi
proceed:
or al, al
jne @B
lea eax, dword ptr [edx+ecx]
xor eax, edx
.if moins == 1
not eax
inc eax
.endif
pop edi
pop esi
ret
satodw endp
> Why only unsigned number ?
Easy, that is what it was designed to do. I am not personally a fan of multiple combined capacities, just do one of each.
in this case, signed makes sense, though :P
if it's unsigned, there shouldn't be a "-" in front of it - lol
I have posted a modified atodw who accept the sign - and + and signed number.
Quote from: dedndave on October 12, 2014, 05:03:16 AM
if it's unsigned, there shouldn't be a "-" in front of it
Valid point :t
I have always encouraged people to write what they like but this library will retain the distinction between signed and unsigned, I don't support the idea of blending capacities together, its the slippery slope to un-analysed high level objects instead of being components.
To make please everyone,i have recall it satodw,(signed atodw)
OK ?
Try the module "atol proc lpSrc:DWORD", it handles signed DWORD values.
same results and same speed than the satodw.
bad thing,the name made a conflict with the crt function.
The crt function atol add a control of the overflow,-80000000h to 7FFFFFFFh (msdn)
:biggrin:
It does not conflict with crt_atoi which is the form that masm32 calls the MSVCRT dll. The point being that you never ever change an existing functionality of a procedure or you break someone's code. As far as the name, priority is given to procedures in the library over any external procedure names.
BTW what happened to atou (http://masm32.com/board/index.php?topic=1357.msg13795#msg13795)?
:biggrin:
Quote
It does not conflict with crt_atoi
Do not be in conflict with itself is a great success :idea:
You seem to miss it, MASM is not committed to the naming conventions of other compilers and assemblers.
Quote from: hutch-- on October 13, 2014, 08:10:58 PM
You seem to miss it, MASM is not committed to the naming conventions of other compilers and assemblers.
Right. :t That's in principle the freedom and preference of assembly language.
Gunther