FASMLIB 0.4

[vid]

first of all - i still have binaries only first version of dec2hex. But i suppose (in this answer) that the masm32lib procedures are same in both. If I am wrong, you could provide me binaries of second version of dec2hex.

If you look at the "print" macro, it already trims the trailing 13,10 from the input from the console so if you type 9 characters, thats what you get.
your_typed_text,13,10,0

but print macro is used AFTER you check length. so when you are checking length, you check it with two EOL bytes included

I don't know where you get the idea of what is returned by the API used in StdIn, for any text typed it always returns,

no it doesn't, at least  in first binary. The "input" procedure looks like this:

Code Select Expand

00401108  /$ 55             PUSH EBP
00401109  |. 8BEC           MOV EBP,ESP
0040110B  |. 83C4 F8        ADD ESP,-8
0040110E  |. 6A F6          PUSH -0A                                 ; /DevType = STD_INPUT_HANDLE
00401110  |. E8 F7000000    CALL <JMP.&kernel32.GetStdHandle>        ; \GetStdHandle
00401115  |. 8945 FC        MOV DWORD PTR SS:[EBP-4],EAX
00401118  |. 6A 07          PUSH 7                                   ; /Mode = ENABLE_PROCESSED_INPUT/OUTPUT|ENABLE_LINE_INPUT/WRAP_AT_EOL|ENABLE_ECHO_INPUT
0040111A  |. FF75 FC        PUSH DWORD PTR SS:[EBP-4]                ; |hConsole
0040111D  |. E8 02010000    CALL <JMP.&kernel32.SetConsoleMode>      ; \SetConsoleMode
00401122  |. 6A 00          PUSH 0                                   ; /pOverlapped = NULL
00401124  |. 8D45 F8        LEA EAX,DWORD PTR SS:[EBP-8]             ; |
00401127  |. 50             PUSH EAX                                 ; |pBytesRead
00401128  |. FF75 0C        PUSH DWORD PTR SS:[EBP+C]                ; |BytesToRead
0040112B  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]                ; |Buffer
0040112E  |. FF75 FC        PUSH DWORD PTR SS:[EBP-4]                ; |hFile
00401131  |. E8 F4000000    CALL <JMP.&kernel32.ReadFile>            ; \ReadFile
00401136  |. 8B45 F8        MOV EAX,DWORD PTR SS:[EBP-8]
00401139  |. C9             LEAVE
0040113A  \. C2 0800        RETN 8

and ReadFile doesn't zero-terminate. Also, the returned size is size of readen data

Where we differ is in what target we are pointing code at. If the only market was the low to medium level of C programming, the type of design that encapsulates idiot proof procedures would be appropriate but with assembler programmers who are generally after performance and size of code, slow idiot proof procedures are little use to them. I have only ever catered for assembler rogrammers who will use something if its useful, modify it if its close to useful or simply write their own if they can do it better to suit what they need.

But this is not about being idiotproof to programmers. This is about being idiotproof to users, which is IMO always required in maximal possible range. If programmers want to use your routines to create user-idiotproof app, they must code, for every routine, twice it's size of checks.

I believe most coders want to create tools which ARE idiotproof to users. Could you show me example how to write such user-idiotproof dec2hex with masm32lib? (binary included please - i don't have working masm32 installed)

[hutch--]

It is evident that you don't know enough about masm and the masm32 project to analyse its capacity. I have attached the test piece for the "input" macro that shows that it always returns the correct character count. This is the result.

Code Select Expand


H:\asm3\input>input
Enter characters to count input length > 1234
You have entered 4 characters
Press any key to continue ...

H:\asm3\input>input
Enter characters to count input length > 1234567890
You have entered 10 characters
Press any key to continue ...

H:\asm3\input>input
Enter characters to count input length > abcdefghijklmnopqrstuvwxyz
You have entered 26 characters
Press any key to continue ...

H:\asm3\input>input
Enter characters to count input length >
You have entered 0 characters
Press any key to continue ...

H:\asm3\input>input
Enter characters to count input length > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
You have entered 128 charactersPress any key to continue ...


Put simply you cannot break it because it properly controls its input buffer length. It handles no input at all, 0 length to input in excess of its 128 character limit from the console.

I have actually bothered to download your library and had a look at it, for you to try and make comparisons to the masm32 library, you would need to know something about it and all of this stuff builds with the current masm32 project.

With the attached zip file, I have included the DumpPE disassembly so that you can find the bits you have missed. The StdIn procedure always returns 13,10,0 at the end of it. It is then tail end trimmed by a procedure as follows from the dump.

Code Select Expand


00401130                    fn_00401130:                ; Xref 00401049
00401130 55                     push    ebp
00401131 8BEC                   mov     ebp,esp
00401133 8B5508                 mov     edx,[ebp+8]
00401136                    loc_00401136:               ; Xref 0040113B
00401136 8A02                   mov     al,[edx]
00401138 42                     inc     edx
00401139 3C0D                   cmp     al,0Dh
0040113B 75F9                   jnz     loc_00401136
0040113D B000                   mov     al,0
0040113F 8842FF                 mov     [edx-1],al
00401142 C9                     leave
00401143 C20400                 ret     4


Now rather than try and make comparisons to a library that is very well accepted over years of reliable use, it is probably better that you concentrate on improving your own library as it is a fundamentally good idea with FASM being portable across Windows and Linux. If you can find a way around the multiple builds you can beat the granularity problem and produce minimum sized executables which FASM is easily capable of doing.

Using C libraries as reference is off the pace for pure assembler libraries, if you don't care about the bloat and speed issues, you would be better off writing the libraries in C but I can assure you that a properly written set of library procedures in FASM will eat a C compiler alive.

LATER: Sorry about that. I have attached the file.

[attachment deleted by admin]

[vid]

seems you forgot the attachment :(

so i forced myself to install masm32 (even tough to root directory). I already had the sources, but i want to be able to build binaries to demonstrate what i want to say.

I am sorry for saying input is not zero-terminated. It is done by StripLF, but not properly. Read further please.

The StdIn procedure always returns 13,10,0 at the end of it.

No, it doesn't. It reads up to 80 characters from input. If there is CRLF on input (not nescessary), it stops on it. Stdin then returns size of readen data in EAX, which is then trashed by input macro. No zero termination is done by ReadFile in StdIn, try to initialize buffer with nonzero value and see it for yourself.

Zero termination is done by StripLF, which doesn't have any buffer overrun checking. This means that if input doesn't contain 13,10, it fails.

BUT, none of your procedures is ready for typed input size (without end-of-line) equal to 128 (80h) characters. In such case, buffer overflow occurs. Such input is valid on win32, so i consider this a bug that cannot be avoided using masm32lib. I can provide binary example if you wish, but it should be enough to see it from code:

Code Select Expand

   input MACRO prompt:VARARG
        LOCAL txt
        LOCAL buffer
      IFNB <prompt>
        .data
          txt db prompt, 0
          buffer db 128 dup (0)
          align 4
        .code
        invoke StdOut,ADDR txt
        invoke StdIn,ADDR buffer,LENGTHOF buffer  ;calls stdin with 80h size
        invoke StripLF,ADDR buffer
        mov eax, offset buffer
        EXITM <eax>
      ELSE
        .data
          buffer db 128 dup (0)
          align 4
        .code
        invoke StdIn,ADDR buffer,LENGTHOF buffer
        invoke StripLF,ADDR buffer
        mov eax, offset buffer
        EXITM <eax>
      ENDIF
    ENDM

Code Select Expand

StdIn proc lpszBuffer:DWORD,bLen:DWORD

    LOCAL hInput :DWORD
    LOCAL bRead  :DWORD

    invoke GetStdHandle,STD_INPUT_HANDLE
    mov hInput, eax

    invoke SetConsoleMode,hInput,ENABLE_LINE_INPUT or \
                                 ENABLE_ECHO_INPUT or \
                                 ENABLE_PROCESSED_INPUT

    ;reads up to 128 characters, which doesn't nescessary contain CRLF.
    invoke ReadFile,hInput,lpszBuffer,bLen,ADDR bRead,NULL 

    ;size of readen data (up to 128) is stored in EAX and trashed by input macro
    mov eax, bRead
 
    ret
StdIn endp

Code Select Expand



  ;replaces first character 13 with 0. If there was no eol in 128 typed characters, overflows and
  ;destroys first byte 13 following the buffer

  ;also, in case when stdin is redirected from file, this trashes all data that was read, up to 128 bytes.

  StripLF proc strng:DWORD

    mov edx, strng
  @@:
    mov al, [edx]
    inc edx
    cmp al, 13   ;this is CR character,  LF is 10, but anyway...
    jne @B

    mov al, 0
    mov [edx-1], al

    ret
StripLF endp

My suggested solution is to change code in "input" macro.

From:

Code Select Expand


          buffer db 128 dup (0)
...
        invoke StdIn,ADDR buffer,LENGTHOF buffer  ;calls stdin with 80h size
        invoke StripLF,ADDR buffer

To:

Code Select Expand


buffer db 129 dup(0)  ;make space for endining zero
invoke StdIn,ADDR buffer,LENGTHOF buffer-1  ;calls stdin with 80h size
dec eax
cmp byte ptr [eax], 0Dh  ;typed 79h chars + enter
je found
dec eax
cmp byte ptr [eax], 0Dh ;typed 78h chars or less + enter
jne no_eol ;jumps when user typed 80h chars, no enter
found:
mov byte ptr [eax], 0
no_eol:


stripLF causes bug here and is competely not needed. This way you can safely read input with size equal to 80h bytes. But still it doesn't work good enough for input redirected from file

[vid]

also one more note about wasting space with fasmlib .obj (not .lib):

you are right about this, and i will try to find a solution. But look at yourself - define buffer for data EVERY TIME caller uses input macro??? This is not much better

[hutch--]

One of the virtues of writing a library is to document the results and that is what the help files are for. StdIn returns the written byte length to the buffer supplied and if you need to truncate the string, it is very simple to do. Likewise the "input" macro is documented in the high level help file and it does what it is supposed to do, provide simplified console text input.

Part of what you are assuming is that of unintentional consequences from using the macro in a manner it is not documented to do. If you want far larger redirected input, you use the StdIn procedure with a large enough input buffer to hold what you point at it.

Now with this following example, I have added a bin2hex algo that drags in a 512 byte hex table yet the exe still builds at 2.5k, the virtue of proper library design with granularity issues is you never get more code than you need.

Below is an example which I will endeavour to attach this time.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

comment * -----------------------------------------------------
                        Build this  template with
                       "CONSOLE ASSEMBLE AND LINK"

            This test piece is designed to test redirection
                     on the windows.inc include file
        ----------------------------------------------------- *

    megabyte equ <1024*1024>

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    call main

    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc

    LOCAL pbuf  :DWORD
    LOCAL phex  :DWORD
    LOCAL blen  :DWORD

    mov pbuf, alloc(megabyte*2)     ; allocate a 2 meg buffer
    mov phex, alloc(megabyte*8)     ; 4 times larger for hex buffer

    invoke StdIn,pbuf,megabyte*2    ; get standard input
    mov blen, eax                   ; store the written length

    mov ecx, pbuf
    mov BYTE PTR [ecx+eax], 0       ; truncate output to written length
    add blen, 1                     ; display the terminator as well

    print "Input length of redirected file = "
    print str$(blen),13,10

    invoke bin2hex,pbuf,blen,phex   ; convert the file to hex notation

    print "Output length of written file = "
    print str$(len(phex)),13,10

    test OutputFile("yourfile.txt",phex,len(phex)), eax

    free phex
    free pbuf

    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


If I bother to tweak the "input" macro it will be to place the buffer in the uninitialised data section so it does not increase the exe file size as truncating the text with a trailing zero is one instruction.

Lastly, while it does not effect the macros operation, the StripLF algo should test for zero. One of the young members found this a few years ago but I forgot about it. Here is its replacement.

Code Select Expand


; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

StripLF proc src:DWORD

    mov eax, [esp+4]
    sub eax, 1
  @@:
    add eax, 1
    cmp BYTE PTR [eax], 0
    je tlfout
    cmp BYTE PTR [eax], 13
    jne @B

    mov BYTE PTR [eax], 0
    ret 4

  tlfout:
    ret 4

StripLF endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

[attachment deleted by admin]

[vid]

not really

Description
The input macro receives text input from the console and returns the address of that text. The text cursor or the prompt and text cursor is set at the current location on the console.

Parameters
   1. Optional quoted text and character notation.

Return Value
The return value is the address of the text typed at the console.

Comments
By convention, STDIN appends a carriage return / line feed pair of characters to the end of the text typed at the console. The input macro calls a seperate function that removes the CRLF pair so that the input text can be directly converted to numeric data without any problems.

you see your mistake again:

By convention, STDIN appends a carriage return / line feed pair of characters to the end of the text typed at the console

No, it doesn't. There is no such convention, and this is not true in every case. That is why you have bug in stdin macro.

The current version has a 128 character limit.

No, it has 127 character limit. If you type 128 characters then StripLF overflows and overwrites following data.

If I bother to tweak the "input" macro it will be to place the buffer in the uninitialised data section so it does not increase the exe file size as truncating the text with a trailing zero is one instruction.

still it wastes size of memory required by program, which wouldn't be needed.

Lastly, while it does not effect the macros operation, the StripLF algo should test for zero. One of the young members found this a few years ago but I forgot about it. Here is its replacement.

Still it is not enough. In case user types 128 'a' characters, then your 128 byte buffer will be filled. If following align doesn't produce any 0 bytes, then it still overflows. One solution would be to also declare your buffer this way:

Code Select Expand

buffer db 128 dup(?)
db 0 ;prevent overflow

But this is still not right. Only thing that "convention" assures you about size of input, is the value returned in eax from StdIn.

[vid]

one more note to wasting precious 6 kilobytes with my obj: Why the hell size of hex output is 4 times size of binary??? I always thought hex representation is 2 times bigger than binary  ::)

In your example, it's 4 MB of wasted space!

[hutch--]

I am not all together sure what you wish to acheive with nitpicking at examples when the problem you have with your library design is un-necessary code that is not called by the application but gets included anyway. You need to solve the granularity problem by seperating the procedures into seperate modules. FASM is easily capable of producing minimum sized objct modules so its not a technical limit of FASM, its your bundling so many procedures together.

> one more note to wasting precious 6 kilobytes with my obj: Why the hell size of hex output is 4 times size of binary??? I always thought hex representation is 2 times bigger than binary

Code Select Expand


00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00


Lack of attention to detail is what causes crashes. The hex format which the algo produces is 49 bytes long for each line plus 2 bytes CRLF for each 16 bytes of binary data, 51 being 3 bytes over 48 bytes which is 3 times 16. Allocate 3 times the buffer size and watch you code go BANG when it writes past the end of the buffer.

You have kept labouring on a number of misconceptions about how much of this code works, zero terminated strings have been with us for a very long time and everyone knows how they work. What you can get with the examples you have been nitpicking is if you enter more text than the allocated buffer, it will get truncated to the length of the buffer so there is no CRLF to strip off the end of the buffer.

This is in fact what you would expect it to do if you choose to enter the full buffer length possible from the console. This was the point of posting the following output.

Code Select Expand


H:\asm3\input>input
Enter characters to count input length > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
You have entered 128 charactersPress any key to continue ...


Contrary to your opinion, the macro and the procedures behind it cannot be broken from the command line with either maximum length console input or pressing enter with no other text entered. It is irrelevant what may happen in a Unix based OS when this code is designed to work in a Windows console and nothing else and the API code behind it will not run on anything else. This stuff was very rigorously tested when it was written and has been working reliably ever since.

Now you are simply mistaken with Windows console input,not only does it accept the characters you type at the console but it writes the 13,10 to the buffer as well when you press the enter key so when you test the bytes written count, you get the typed text AND the CRLF. The reason why you normally trim the 13,10 off the end is so it does not effect passing the number to various conversions. It is a matter of some indifference as to what happens in a Unix console or a mac or mips or whatever else when the convention for a Windows console since the introduction of 32 bit Windows does it by including the CRLF into the buffer.

[vid]

I am not all together sure what you wish to acheive with nitpicking at examples when the problem you have with your library design is un-necessary code that is not called by the application but gets included anyway. You need to solve the granularity problem by seperating the procedures into seperate modules. FASM is easily capable of producing minimum sized objct modules so its not a technical limit of FASM, its your bundling so many procedures together.

the problem arises only when using MSCOFF version of library. FASM code can use FASMLIB directly by sources, so no unneeded code gets defined. But, as i told you two or three times, i agree this should be solved, and i will try to solve it.

The hex format which the algo produces is 49 bytes long for each line plus 2 bytes CRLF for each 16 bytes of binary data, 51 being 3 bytes over 48 bytes which is 3 times 16. Allocate 3 times the buffer size and watch you code go BANG when it writes past the end of the buffer.

You are right, sorry. I had misconception about your bin2hex

about the bug: seems there is no other way to exaplain that to you, but to provide example. Attached is example of bug, with source code. If you feel i altered attached masm32 files, just replace them with original ones from masm32 package.

here is the source:

Code Select Expand

; #########################################################################

      .586
      .model flat, stdcall
      option casemap:none    ; case sensitive

; #########################################################################

      include kernel32.inc
      include masm32.inc
      include macros.asm

; #########################################################################

.data
db 0,0


.code

start:

mov check, 13
mov eax, input("Enter 128 chars: ")
cmp check, 13
je okay

print "MASM32LIB is buggy"

okay:
exit


; #########################################################################
.data

check dd 0

end start
quess what happens when you type 128 characters

[attachment deleted by admin]

[MichaelW]

When I build your source using the proper masm32.lib, and run it, I get nothing. Entering anywhere from 125 to 130 characters, check is not overwritten.

[hutch--]

I just pasted your code into the editor, slightly modified it so it would build in masm32 and here is the source and result.

Code Select Expand


; #########################################################################

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

;       .586
;       .model flat, stdcall
;       option casemap:none    ; case sensitive

; #########################################################################

;       include kernel32.inc
;       include masm32.inc
;       include macros.asm

; #########################################################################

.data
db 0,0

.code

start:

mov check, 13
mov eax, input("Enter 128 chars: ")
cmp check, 13
je okay

print "MASM32LIB is buggy"
jmp not_ok

okay:
print "Seasons Greetings from the MASM32 Library",13,10
exit

not_ok:
exit

; #########################################################################
.data

check dd 0

end start


The result.

Code Select Expand


F:\posted_demo>pd
Enter 128 chars: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Seasons Greetings from the MASM32 Library
F:\posted_demo>


The input from the console is well over 128 bytes yet it runs correctly as it in fact always has done. It is truncated to 128 characters if this excessive input is entered from the console.

Both the "input" and "print" macros in part emulate a very old basic format from early ROM basic and it is done so for ease of use, Console IO is trailing edge technology and there is little to acheive apart from making it easy o use and reliable.

Note that this code was built using the old "StripLF" that exists in the current masm32 distribution, even though it only checks for ascii 13 and not zero.

[vid]

I just pasted your code into the editor, slightly modified it so it would build in masm32 and here is the source and result.

so you say, you found case in which it works? Well, i found case in which it doesn't work. Quess what this means.

If you find one case where it doesn't work when it should - it's a bug. If you find case where it works when it should - means nothing.

And even in your "working" example, character 13 of "Seasons Greetings..." string is overwritten by StripLF. You can check by redirecting output to file and looking at it's contents - no 13 or 10 will be there.

Man, you really deserve your own article on DailyWTF.

[hutch--]

Now to put this nonsense properly to rest, here is formal proof that the "input" macro does what it is published to do.

The source.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

comment * -----------------------------------------------------
                        Build this  template with
                       "CONSOLE ASSEMBLE AND LINK"
        ----------------------------------------------------- *

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    call main

    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc

    LOCAL pbuf  :DWORD
    LOCAL phex  :DWORD
    LOCAL lsrc  :DWORD

    mov pbuf, input("Enter Text ",62," ")

    mov lsrc, len(pbuf)             ; get the source length
    add eax, eax
    add eax, eax                    ; mul by 4 to get hex buffer length

    mov phex, alloc(eax)            ; allocate length * 4

    invoke bin2hex,pbuf,lsrc,phex   ; convert source to hex notation

    print phex,13,10                ; display hex output

    free phex                       ; deallocate hex buffer

    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


The result. Exact input up to the specified length in the documentation then truncation to the 128 character input. Test on Win2000 sp4 CMD.EXE.

Code Select Expand


F:\posted_demo\tst>tst
Enter Text > Seasons greetings from the MASM32 Library :)
53 65 61 73 6F 6E 73 20 - 67 72 65 65 74 69 6E 67
73 20 66 72 6F 6D 20 74 - 68 65 20 4D 41 53 4D 33
32 20 4C 69 62 72 61 72 - 79 20 3A 29

F:\posted_demo\tst>tst
Enter Text > ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
F:\posted_demo\tst>tst
Enter Text > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqq
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
F:\posted_demo\tst>


[hutch--]

Seems we cross posted, you are missing something with the macro, it is supposed to trim the trailing CRLF off the input string and it does this by writing a zero in the place of the first occurrence of ascii 13. Enter input in excess of 128 characters and it gets truncated to 128 bytes as the last posting proves.

Thank you again for verifying the exact output of the macro as per its specification.  :bg

[vid]

Yes, input does what it should. Plus, it does some extra unwanted stuff in some cases. The binary i posted (m32lib_bug) is proof it really does. It overwrites the value 13 to value 0. Is input macro intended to do this? This is major question, please reply to it: Is input macro intended to overwrite data behind the read buffer?. I provided clear example, that under certain circumstances, it does this.

you are missing something with the macro, it is supposed to trim the trailing CRLF off the input string and it does this by writing a zero in the place of the first occurrence of ascii 13. Enter input in excess of 128 characters and it gets truncated to 128 bytes as the last posting proves.

and exactly here is the error. Input is truncated to 128 bytes, and these bytes doesn't contain any character 13. This means "nearest character 13" is outside the buffer. Just like in my example. Even adding check for byte 0 to StripLF is not enough. After input is truncated to 128 bytes, it is not zero-terminated. There is 1:4 chance that zero is generated by following "align", but 25% is still not 0%