EDIT: Damn I forgot to send my messages to [email protected] . I only
answered roger. Here are the missing messages:
FIRST ONE:
oh...I didn't know it was a buge
I thought, I just didn't understand the code :)
(Actually I even didn't run the program yet, for I like to understand the code
fully before trying it)
> Subject: Re: [Pgubook-readers] Chapter 5, toupper-program: understanding
> the read loop
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [email protected]
> Date: Sat, 17 May 2008 20:32:41 -0800
>
> I believe this is a known bug for this part of the book.
>
> It's simple to fix once you understand the bug. ;-)
>
> If you check the archives, you'll find the answer. Maybe another poster
> remembers the specifics for this program.
>
>
> On Sat, 2008-05-17 at 13:10 +0000, david helfgott wrote:
> > Hi there !
> >
> > I got some serious problems with understanding the read loop in the
> > toupper programm.
> >
> > Where does the computer know to start again from, after the "jmp
> > read_loop begin" ?
> >
> > Why doesn't the computer always reads the same first 500 bytes into
> > the buffer ?
> >
> > Where does he knows from, where he has to continue ?
> >
> > after the "jmp read_loop begin" he starts again at
> >
> > movl $SYS_READ, %eax
> > movl $ST_FD_IN(%ebp), %ebx
> > movl $BUFFER_DATA, %ecx
> > movl $BUFFER_SIZE, %edx
> > int $LINUX_SYSCALL
> >
> > that's exactly the same information he got in the first place.
> >
> > So if I have a file conatining 700 bytes.
> > Where does he know from to start reading at byte No. 501 in the secon
> > run, and not just read the first 500 bytes again ?
> >
> > Where's the extra information, that tells him, he already red the
> > first 500 bytes and has to read the next 500 byte ?
> >
> >
> >
> >
> >
> > ####################
> >
> > read_loop_begin:
> >
> > ###READ IN A BLOCK FROM THE INPUT FILE###
> >
> > movl $SYS_READ, %eax
> >
> >
> > #get the input file descriptor
> >
> > movl ST_FD_IN(%ebp), %ebx
> >
> >
> > #the location to read into
> >
> > movl $BUFFER_DATA, %ecx
> >
> >
> > #the size of the buffer
> > movl $BUFFER_SIZE, %edx
> >
> >
> > #Size of buffer read is returned in %eax
> >
> > int $LINUX_SYSCALL
> >
> >
> > ###EXIT IF WE’VE REACHED THE END###
> > #check for end of file marker
> >
> > cmpl $END_OF_FILE, %eax
> >
> >
> > #if found or on error, go to the end
> >
> > jle end_loop
> >
> >
> > continue_read_loop:
> > ###CONVERT THE BLOCK TO UPPER CASE###
> >
> > pushl $BUFFER_DATA #location of buffer
> > pushl %eax #size of the buffer
> > call convert_to_upper
> > popl %eax #get the size back
> > addl $4, %esp #restore %esp
> >
> >
> >
> > ###WRITE THE BLOCK OUT TO THE OUTPUT FILE###
> > #size of the buffer
> >
> > movl %eax, %edx
> > movl $SYS_WRITE, %eax
> >
> > #file to use
> > movl ST_FD_OUT(%ebp), %ebx
> >
> > #location of the buffer
> >
> > movl $BUFFER_DATA, %ecx
> > int $LINUX_SYSCALL
> >
> >
> > ###CONTINUE THE LOOP###
> > jmp read_loop_begin
> > end_loop:
> >
> >
> > ###CLOSE THE FILES###
> > #NOTE - we don’t need to do error checking
> > # on these, because error conditions
> > # don’t signify anything special here
> > movl $SYS_CLOSE, %eax
> > movl ST_FD_OUT(%ebp), %ebx
> > int $LINUX_SYSCALL
> > movl $SYS_CLOSE, %eax
> > movl ST_FD_IN(%ebp), %ebx
> > int $LINUX_SYSCALL
> > ###EXIT###
> > movl $SYS_EXIT, %eax
> > movl $0, %ebx
> > int $LINUX_SYSCALL
> >
> > #######################
> >
> >
> > ______________________________________________________________________
> > Windows Live Messenger - Schreiben. Sehen. Hören. Wie im echten Leben.
> > Windows Live Messenger!
> > _______________________________________________
> > Pgubook-readers mailing list
> > [email protected]
> > http://lists.nongnu.org/mailman/listinfo/pgubook-readers
> --
> Roger
> http://www.eskimo.com/~roger/index.html
SECOND ONE
I forgot to mention, that my search on the archive was not sucessfull :-(
THIRD ONE
Hi guys!
Thank you for your help !
Nevertheless I think you some kind of misunderstood me :-)
I didn't said that the actual program had a bug. I said, I didn't understand a
certain thing at the program.
I tried using the program with a buffer-size of 1 byte and it still worked.
There's no bug :-(
So anyone has a clue where the computer knows from, where to start again after
the first read loop ?
> Subject: RE: [Pgubook-readers] Chapter 5, toupper-program: understanding
> the read loop
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [email protected]
> Date: Tue, 20 May 2008 12:28:20 -0800
>
>
> On Tue, 2008-05-20 at 11:09 +0000, david helfgott wrote:
> > I forgot to mention, that my search on the archive was not
> > sucessfull :-(
> >
> I'm not an official monitor of this list, nor do I program everyday
> using Assembly. I am only subscribed to the mailing list.
>
> Just be weary of a bug in one or two programs.
>
> They're simple enough, you should be able to fix them once you realize
> books have a possibility of container errors! (I had a slight difficult
> time realizing this possibility as I thought all Linux related were
> perfect.)
>
> Sept/Oct 2007 seems to contain quite a bit of activity on this list,
> however, none since then.
>
> The book is still excellent supplement material for any programming
> class, aside from one or two of the known bugs.
>
> --
> Roger
> http://www.eskimo.com/~roger/index.html
FOURTH ONE
> >
> Well, now you're in the know concerning a bug in a couple of programs.
>
Of course. That's something important and will change my way of reading the
book.
I still want to know how the computer works witht the buffer >:-(
I just can't sleep at night quietly with this problem still unsolved.
If I manage to get the answer I'll post it here. Nobody should ever suffer the
same way I do
XD
_________________________________________________________________
Völlige Gestaltungsfreiheit: Mit Live.com können Sie Ihre Homepage genau so
gestalten, wie Sie es möchten.
http://www.live.com/getstarted
_______________________________________________
Pgubook-readers mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/pgubook-readers
