Re: Programming in standard c
- From: user923005 <dcorbit@xxxxxxxxx>
- Date: Thu, 27 Dec 2007 13:34:00 -0800 (PST)
On Dec 27, 12:21 pm, jacob navia <ja...@xxxxxxxxxx> wrote:
Erik Trulsson wrote:
jacob navia <ja...@xxxxxxxxxx> wrote:
I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
Your imagination is obviously not very good.
Take for example CP/M.
This system is a good example of a currently widely
used system isn't it?
The solution for that system is very simple.
filesize reports number of blocks times the size of each block.
Period. Of course this is not the size of the useful bytes but...
who cares? CP/M users know that!
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
Next Cmd: dir/size
Directory DKA0:[000000.CONNX75.VMS-BINARIES]
LINK.COM;6 2
VAXCRTL.OPT;6 1
ZIP.AXP_OLB;6 730
ZIP.HLP;6 49
ZIP.I64_OLB;6 871
ZIP.VAX_DECC_OLB;6 218
ZIP.VAX_VAXC_OLB;6 201
ZIPCLI.AXP_OLB;6 292
ZIPCLI.I64_OLB;6 459
ZIPCLI.VAX_DECC_OLB;6
96
ZIPCLI.VAX_VAXC_OLB;6
84
ZIPCLOAK.AXP_OBJ;6 61
ZIPCLOAK.I64_OBJ;6 54
ZIPCLOAK.VAX_DECC_OBJ;6
22
ZIPCLOAK.VAX_VAXC_OBJ;6
22
ZIPNOTE.AXP_OBJ;6 70
ZIPNOTE.I64_OBJ;6 60
ZIPNOTE.VAX_DECC_OBJ;6
26
ZIPNOTE.VAX_VAXC_OBJ;6
26
ZIPSPLIT.AXP_OBJ;6 81
ZIPSPLIT.I64_OBJ;6 83
ZIPSPLIT.VAX_DECC_OBJ;6
31
ZIPSPLIT.VAX_VAXC_OBJ;6
29
ZIPUTILS.AXP_OLB;6 240
ZIPUTILS.I64_OLB;6 432
ZIPUTILS.VAX_DECC_OLB;6
62
ZIPUTILS.VAX_VAXC_OLB;6
59
ZIP_CLI.HLP;6 43
Total of 28 files, 4404 blocks.
Next Cmd:
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want.
http://h71000.www7.hp.com/openvms/hw_supportchart.html
Another example would be a file stored on a magnetic tape. There it might not be
possible to find out how large the file is without reading the file until
you reach an end-of-file marker. I am fairly certain that such devices
are still in use.
so what?
filesize searches till the end of the file is found or if the device is
not supported returns an error.
What is obvious is that there are two alternatives:
1) Take the worst possible file system. Then standardize only
what that file system supports.
2) Take the most common situation for current machines and file
systems and standardize what those systems support.
Obviously you support (1). Everybody has to take care of CP/M,
that disappeared more than 20 years ago, System 3090, that disappeared
more or less at the same date...
Yours is the easiest solution: keep C at the PDP-11 / CP/M System 3090
level.
I would propose that those obsolete systems aren't even considered.
If someone implements C in them, then, it is up to the implementation
to see how the standard can be implemented.
For instance, and to go on with CP/M you could store the number
of used bytes in each block at the last 2 bytes of each block
isn't it?
Not very difficult to do.
The fact that sizes are not reported in bytes on some systems is not
nearly so large a hurdle as the fact that on live systems file sizes
are constantly changing. You are proposing a function that cannot
possibly work (reporting file size on a live file). It's not an
intelligent API.
.
- Follow-Ups:
- Re: Programming in standard c
- From: Bart C
- Re: Programming in standard c
- From: jacob navia
- Re: Programming in standard c
- References:
- Programming in standard c
- From: jacob navia
- Re: Programming in standard c
- From: jameskuyper
- Re: Programming in standard c
- From: jacob navia
- Re: Programming in standard c
- From: Erik Trulsson
- Re: Programming in standard c
- From: jacob navia
- Programming in standard c
- Prev by Date: Re: Programming in standard c
- Next by Date: Re: Programming in standard c
- Previous by thread: Re: Programming in standard c
- Next by thread: Re: Programming in standard c
- Index(es):
Relevant Pages
|