checking for end of line

[travism]

This is like the simpliest thing and for some reason i dont know why this wont work here is the numerous attempts ive had im trying to test for a new line/end of line

Code Select Expand


cmp byte ptr [ebx],13
je    blah

cmp byte ptr [ebx],VK_RETURN
je    blah


Is there another way to test for it or ??

[dedndave]

usually, text lines end with 13,10
when i write parsers, i look for any combo of 13's/10's, as i have seen all possibilities
you don't want to start parsing the next line until you have found it - lol
i dunno what is going on there, Travis

[travism]

shoulda mentioned i did do a test to make sure the last to chars were 13,10 also so im a bit puzzled now... C they just make it to easy lol

[dedndave]

well - i have seen some crazy stuff
i have seen lines ending with only CR
i have seen lines ending with only LF
i have seen lines ending with LF,CR (reversed)
technically, they are all valid EOL's

[bruce1948]

I believe the LF, CR is the Macintosh variant :dazzled:

[ramguru]

jeez, guys .. you forgot unicode  :wink
so number of combination doubles  :lol

don't say your assembler won't support unicode  :naughty:

[dedndave]

me no speakum unicode
me also no speakum 64-bit - lol

[FORTRANS]

Hi,

  Like dedndave I have seen various end-of-lines.  CR for Mac's
LF for Linux et. al..  CR, LF for DOSish.  LF, CR when I got things
backward.  Plus things like CR, LF, LF, LF.  And if you want to look
for problems, if ANSI.SYS is loaded, you can end a line using an
escape sequence.  Plus end of file or data.  And these are for
just (more or less) plain text.

Regards,

Steve N.

[NightWare]

the problem come from another part of your Code, you have possibly forgotten to test the final zero before...

a classic procedure :

Code Select Expand

ALIGN 16
;
; get the number of lines of a string/text
;
; syntax :
; mov ebx,Text Address
; call  GetLines
;
; Return :
; eax = number of lines of the text
;
GetLines PROC
push ebx ; empiler ebx
push edx ; empiler edx

xor eax,eax ; on efface eax
cmp BYTE PTR [ebx],0 ; comparer l'octet que l'on vient de lire à 0
jz Label2 ; si l'octet est égal à 0, aller Label2 (car eax = 0)
; nop ; ) aucun alignement nécessaire pour un meilleur rendement
; nop ; )
; nop ; )
; nop ; )
; nop ; )
; nop ; )
; nop ; )
; nop ; )
Label1: mov dl,BYTE PTR [ebx] ; placer l'octet à l'adresse en ebx dans dl
inc ebx ; augmenter ebx
cmp dl,0 ; comparer l'octet que l'on vient de lire à 0
je Label2 ; si l'octet est égal à 0, aller Label2
cmp dl,13 ; comparer l'octet que l'on vient de lire à une fin de ligne
jne Label1 ; si c'est différent, aller Label1
cmp BYTE PTR [ebx],10 ; comparer l'octet suivant à une nouvelle ligne
jne Label1 ; si c'est différent, aller Label1
inc eax ; sinon, on ajoute 1 à notre compteur
jmp Label1 ; et on retourne au Label1
Label2: inc eax ; sinon on ajoute 1 à notre compteur

pop edx ; désempiler edx
pop ebx ; désempiler ebx
ret ; retourner (sortir de la procédure)
GetLines ENDP

[ramguru]

IMO it's a bad idea to assume that file ends with \00 byte
..if not totally wrong
File ends where its size says it does.

[dedndave]

that is true, however, if he is reading an ASM file, it should end where the END directive is
btw - i think the EOF char is 26

[NightWare]

IMO it's a bad idea to assume that file ends with \00 byte
..if not totally wrong
File ends where its size says it does.

:dazzled: ??? noone assume a file end with zero, we just assume it's the case IN MEMORY (where we work !).

[dedndave]

yes - in "text world" (lol), 0 or "null" is treated as a "white space" char (so is 255)

[ramguru]

:dazzled: ??? noone assume a file end with zero, we just assume it's the case IN MEMORY (where we work !).

yeah .. it's the same thing
you should check not for \00 byte
but when the last byte is read
I mean:

Code Select Expand

xor  ecx,ecx
@@:
mov al,[esi+ecx]
...
inc ecx
cmp ecx, fileSize
jnz  @B

that is true, however, if he is reading an ASM file, it should end where the END directive is
btw - i think the EOF char is 26

EOF is condition :} not a char.. you can only tell that's EOF by the size of the file

[dedndave]

EOF is condition :} not a char.. you can only tell that's EOF by the size of the file

i agree, but all parsing may stop at the END directive
i have noticed, as an example, that reg files exported from regedit or regedt32 have characters beyond the EOF
try it out
export (i.e. create) a reg file using regedit
then open it with notepad
then open it with a hex editor and look for the EOF by size
and look at all the stuff at the end of the file
(i think it is the binary reg equiv of the text)

EDIT
eof is a condition, but in text files, there is a character that is assigned EOF (chr$(26))
anything past the EOF character is to be ignored