Prev: Call for Papers: The 2010 International Conference of Signal and Image Engineering (ICSIE 2010)
Next: GMSK recover from I, Q sample data
From: glen herrmannsfeldt on 27 Feb 2010 15:57
Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:
(snip)

> The whole idea of separate text and binary files have crept to
> pure C as afterthoughts because of e.g. CP/M and its descendant
> MS-DOS. The C I/O was originally built for and with Unix. The
> Unix-like systems do not separate binary and text files, but
> most implemenations are polite enough to tolerate the 'b'
> specifier.

> The original CP/M file system counted only reservation blocks
> of 128 bytes each. The size comes from the original 2002 block
> 8 inch single-density diskettes, which were the media for the
> original CP/M. (My first Z80 computer run CP/M 1.3, aeons ago).

Well, it gets more interesting on IBM mainframe systems.
IBM doesn't use a record termination character. The two popular
formats are FB (Fixed length blocked records, where the record
length is known and constant), and VB (variable length blocked
records witha a four byte block descriptor at the beginning of
each block, and a four byte record descriptor at the beginning
of each record.) I believe for text files it adds/removes
'\n' (which might be other than X'0A' in EBCDIC). For non-text
files, I believe by default it doesn't give the BDW and RDW, but
you can get those as an option.

It gets more interesting with fseek() and ftell(). The file
system keeps track of blocks and tracks, but not bytes.
The system can easily seek to a block and offset within a
block, but not to a byte offset. For some systems, ftell()
returns 32768*(block number)+(block offset), and fseek()
accepts those values. Read the C standard description of
fseek() and ftell() for text files.

-- glen
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Call for Papers: The 2010 International Conference of Signal and Image Engineering (ICSIE 2010)
Next: GMSK recover from I, Q sample data