Well... no...
bits 32
section .data
section .text
global l_gets
l_gets:
push ebp ; prologue, set up stack frame
mov ebp, esp
xor eax, eax ; zero eax to prepare for syscall #
push ebx ; preserve ebx
mov ebx, [ebp + 8] ; fd parameter goes into ebx
mov ecx, [ebp + 12] ; char *buf stored into ecx
mov edx, [ebp + 16] ; len stored into edx
mov eax, 3 ; sys call for read
int 0x80
Up to here, I follow you. In fact, it looks like you're about done...
; read data onto stack:
.buf_loop:
; read each character one at a time, increment counter (in eax), when counter matches len, jump out of loop
xor eax, eax ; zero eax to be used for counter
If you zero eax in the loop, it's going to run for a long time!
push ebx ; push the character onto stack
inc ebx ; advance to next character
Last I knew, ebx was your file descriptor...
inc eax ; advance the counter
cmp edx, eax
je .done
Fair enough... if you don't zero eax in the loop...
.loop1:
cmp register, byte 0x0A ; check for newline, exit loop if true
je .done
.done:
I don't see where we "loop", and to where... The last part of it won't even assemble!
After the sys_read, your data's in the buffer that the caller specified, and eax holds bytes read, including the linefeed that ends input. At least that's true if we're reading from stdin. I'm less sure of how sys_read will behave on a "real file" (or, for that matter, if stdin is redirected). If it's a "text file", okay, but what if it's a "binary file"? Are we expected to stop at any number 10 we encounter? I think of "gets()" as being exclusively for stdin, but your assigned "l_gets" is apparently different. I may have to experiment and see what happens on a "real file"...
I mentioned up above that you might want to "flush" any excess. That would apply only to stdin.
Later,
Frank