Re: [Pgubook-readers] Chapter 5: Constants or Labels and other ' concept bugs'

[Roger]

> On Thu, Mar 17, 2011 at 09:31:43PM -0700, TJLAJK TJALJ wrote:
>   Hi,
>
>   I am stumped by the bss declaration on page 82.
>    .section .bss
>   .equ BUFFER_SIZE, 500
>   .lcomm BUFFER_DATA, BUFFER_SIZE
>
>   My question is:
>    How can BUFFER_SIZE be both a label and a constant? How is it possible
>   for the assembler (and programmers) to tell them apart?
>   I have not assembled this code to test-run it yet. Or is the author
>   economical and he should have written it like so:

Going from my own coding experience and not reading from the book currently --
and since nobody is responding readily here -- BUFFER_SIZE is a variable.  The
CPU only deals with numbers and not letters/words.  As such, every label needs
to be converted into a number (or address) that can then be interpreted by the 
CPU.

So, definition of a constant in programming usually means a statically defined
variable (or something non-changing).  Label is another name for variable.
etc...

(I'm just typing from what I can recall and what I think you're trying to
explain.  Hence, I might be totally off-the-ball on this one.)

>   ...
>   .lcomm BUFFER_DATA
>   .lcomm BUFFER_SIZE, 500
>
>   And I think the text has a concept bug, too. On page 82, we have this line
>   of code:
>   #Check for end of file marker
>   cmpl $END_OF_FILE, %eax
>
>   which he explains in the last line of page 92: The system call returns the
>   number of bytes actually read, or end -of-file (the number 0).
>   For beginners like me, this is utter nonsense. I tore my hair over this
>   explanation for quite a while wondering how Linux could return the end of
>   file (\0) number to eax while all it does is return the number of bytes
>   read from the input file. I think this line of text should read like this:
>   The system call returns the number of bytes actually read, and when there
>   are not any bytes left to read, Linux returns the number zero to eax,
>   which signals end-of-file is reached. (I am sorry English is not my mother
>   tounge. But the line should read close to this effect)
>
>   Thank you.

I think you might have stumbled upon one of the first bugs in the book.  I know
it was around this page within code, and I know it's documented someplace but
am quite rusty on Assembly and this book.

The trick is.  Enter and compile the code.  Read and trace the code.  When you
encounter one of the (few) bugs in the book, tracing usually easily reveals the
bug and common sense usually steps in and resolves the rest.

I did read the entire book myself.  Entered and tested all programs (5+ years 
ago).
When I stumbled upon one of the few bugs, I preformed my above suggestions with 
relative
ease.


-- 
Roger
http://rogerx.freeshell.org/