Re: Programming in standard c
- From: user923005 <dcorbit@xxxxxxxxx>
- Date: Fri, 28 Dec 2007 13:31:33 -0800 (PST)
On Dec 28, 1:01 pm, "Serve La" <n...@xxxxxxx> wrote:
"user923005" <dcor...@xxxxxxxxx> schreef in berichtnews:98fef529-1ad1-4870-8760-7f877834452b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Dec 27, 2:01 pm, jacob navia <ja...@xxxxxxxxxx> wrote:
user923005 wrote:
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
[big snip]
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
If you have one of that systems and your trash is full so you can't get
rid of it, then you can do the following
http://h71000.www7.hp.com/wizard/wiz_5424.html
Obtaining RMS file size?
Hello Mr Wizard
I am looking for a method of obtaining the size of a file, NOT the
allocation
from within a Fortran routine. I thought this would be a simple
trivial task
but alas I am proved wrong.
Can you help.
Regards Jim
Answer
RMS does NOT keep track of the number of user data bytes in a file.
The only reliable way to obtain that, is to read the file and count!
So there you have the answer!
If you are using that system expect that filesize() will take some time.
So What?
Should we ALL suffer because some brain-dead system exists somewhere?
remove() is in the standard while there are lots of systems without a
filesystem and where remove doesnt have any meaning. I happen to work on on
such a system now but I dont know what remove does because I just dont need
it and never checked. I'm guessing it returns -1
So why cant a function like filesize() be added? On systems where its
meaningless it could return an error and the programmer can take over with
the byte by byte read or whatever works for him when filesize returned an
error. Whats the logic for adding remove and not adding filesize?
Because filesize can never be anything but an estimate {in the generic
case}. For special types of files, it has meaning. For other file
types it is begging for trouble.
Back to the original question (reading a file into memory), for
systems where this is sensible to do, there is going to exist a memory
map method. Memory mapping can be made relatively portable. That is
a far more sensible solution than simply trying to read a file into
memory (note: memory mapping does a lot more than just reading a file
into memory).
I think that adding a function to the standard library that produces
an unreliable answer has limited utility. The cases where we need the
absolute number will also require lots of guarantees about the file
properties. It is starting to smell operating system specific, n'est
ce pas? For example, someone might use that number to try to read the
file into memory. That is clearly a mistake. Instead, they should
memory map the file if their system supports it.
I guess that filesize() is not in the standard because the C language
implementors thought about it and realized that people might try to
use it. Then, they will have thousands of support calls to handle
when things go wrong.
On the other hand, I think that there was a call somewhere in this
thread for fileinformation() which I think might be a very nice
addition. I guess that even filesize() might not be so bad if they
renamed it currentfilesize(). Then (at least) it would be obvious
that it only contains an estimate.
.
- Follow-Ups:
- Re: Programming in standard c
- From: Gordon Burditt
- 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
- Re: Programming in standard c
- From: user923005
- Re: Programming in standard c
- From: jacob navia
- Re: Programming in standard c
- From: user923005
- Re: Programming in standard c
- From: Serve La
- Programming in standard c
- Prev by Date: Re: setjump and longjump
- 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
|
Loading