Prev: Real Mode,16 bit Programming (Intel x86) on Windows XP?
Next: FIXes - correction, FIX one liner
From: Rosario on 20 Nov 2007 02:08 In data Sun, 18 Nov 2007 14:00:27 -0800 (PST), �ar�nas Kazlauskas scrisse: >... or how do you know you've reached the end of txt file? in the little i know there is not "ascii symbols" for EOF[end of file] i know that the file is end, when fgetc or getc return -1 that is in a macro called "EOF"
From: Terence on 20 Nov 2007 02:26 On Nov 20, 12:45 pm, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk> wrote: > Ctrl-Z in the ASCII standard in use when CP/M and DOS > were being designed is the SUB (substitute) character, > used to indicate that the character was read/received > with some kind of error (e.g. parity error), and this > is a placeholder. There were plenty of "end of <blah>" > characters in ASCII, but 26 wasn't one of them. Ctrl-Z is in fact the correct code to indicate end-of-text from the keyboard. It still works in current MS operating systems and is hunted for in the processing of input from the keyboard when using service calls for keyboard input. NAK is also #1a in asynchronous RS232C protocol, and #11 is ACK.
From: Phil Carmody on 20 Nov 2007 05:52 Charles Crayne <ccrayne(a)crayne.org> writes: > On 20 Nov 2007 03:45:39 +0200 > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > > > Ctrl-Z in the ASCII standard in use when CP/M and DOS > > were being designed is the SUB (substitute) character, > > used to indicate that the character was read/received > > with some kind of error (e.g. parity error), and this > > is a placeholder. There were plenty of "end of <blah>" > > characters in ASCII, but 26 wasn't one of them. > > The Dos 2.00 reference manual has this to say about that: > > "Combining files is normally performed in text (or ASCII) mode. That > is, the first Ctrl-A (hex 1A) character in the file is interpreted as > an end-of-file mark." My point was that this was not an ASCII definition of the meaning of the character. Lots of people are throwing the initialism around as if it were pertinent somehow, it's not. Phil -- Dear aunt, let's set so double the killer delete select all. -- Microsoft voice recognition live demonstration
From: Wolfgang Kern on 20 Nov 2007 09:45 Phil Carmody wrote: >>> Ctrl-Z in the ASCII standard in use when CP/M and DOS >>> were being designed is the SUB (substitute) character, >>> used to indicate that the character was read/received >>> with some kind of error (e.g. parity error), and this >>> is a placeholder. There were plenty of "end of <blah>" >>> characters in ASCII, but 26 wasn't one of them. >> The Dos 2.00 reference manual has this to say about that: >> "Combining files is normally performed in text (or ASCII) mode. That >> is, the first Ctrl-A (hex 1A) character in the file is interpreted as >> an end-of-file mark." > My point was that this was not an ASCII definition of > the meaning of the character. Lots of people are throwing > the initialism around as if it were pertinent somehow, > it's not. Yes, both defininitions for ascii-control and unicode are conform and specifiy char(03h) as EOT 'end of text', while ctrl-A (01h) is SOH 'start of header'. I've seen many variants of text end-marks starting with a single 00h until a bit7-set literally "EOT/EOF" (c5,d0,d4/c6). M$-formats may have changed too often, so my latest text-editor seem to use just the file size to tell the end. __ wolfgang
From: H. Peter Anvin on 20 Nov 2007 19:53 Terence wrote: > On Nov 20, 12:45 pm, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk> > wrote: > >> Ctrl-Z in the ASCII standard in use when CP/M and DOS >> were being designed is the SUB (substitute) character, >> used to indicate that the character was read/received >> with some kind of error (e.g. parity error), and this >> is a placeholder. There were plenty of "end of <blah>" >> characters in ASCII, but 26 wasn't one of them. > > Ctrl-Z is in fact the correct code to indicate end-of-text from the > keyboard. > It still works in current MS operating systems and is hunted for in > the processing of input from the keyboard when using service calls for > keyboard input. > > NAK is also #1a in asynchronous RS232C protocol, and #11 is ACK. RS-232 is a stream of bytes (not necessarily 8-bit ones); it doesn't have any of these kind of symbols. In ASCII, NAK is 0x15, and ACK is 0x06. -hpa
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Real Mode,16 bit Programming (Intel x86) on Windows XP? Next: FIXes - correction, FIX one liner |