Re: Programming in standard c

jacob navia <jacob@xxxxxxxxxx> wrote:
jameskuyper@xxxxxxxxxxx wrote:
jacob navia wrote:
In my "Happy Christmas" message, I proposed a function to read
a file into a RAM buffer and return that buffer or NULL if
the file doesn't exist or some other error is found.

It is interesting to see that the answers to that message prove that
programming exclusively in standard C is completely impossible even
for a small and ridiculously simple program like the one I proposed.

The most portable way to determine the size of the buffer needed to
store a stream that might have been opened in text mode is to use
repeated calls to fread() until the end of file has been reached,
keeping track of the total number of bytes read, and reallocating as
you go along. Sure, it's inefficient;

er... YES!

but for streams which
correspond to devices, rather than files, there's really no
alternative.

We could restrict this to normal files.

Even for streams which correspond to actual files, there
are real OSs where there's no more efficient method of finding the
length of the file.

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. CP/M only keeps tracks of how many disk-blocks
a file uses. It does not keep track of how many bytes are used in each block.
It is normally the case that the last block of a file has one or more unused bytes.
Under CP/M there is no general way of finding out how many of those bytes are
unused for a given file. For text files the end is marked by a CONTROL-Z (this
was later inherited by MS-DOS). For binary files each program will have to come
up with some way of keeping track of that information inside the data files, or
just accept that there may be some garbage bytes at the end of a file.


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.



Maybe there is SOMEWHERE in
the world a crazy file system like that but why should we
care about it?

The world contains many weird file systems and storage devices that are actually
used quite a bit.



--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: FileSystemWatcher across the network
    ... ReadDirectoryChangesW API. ... specify a buffer that the OS will populate with the changes. ... Heavy-weight solutions would be to write a dedicated file system filter ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vb)
  • Re: FileSystemWatcher across the network
    ... didn't state very clear about the buffer size when monitoring network path. ... It's recommended not exceeds 64K when monitoring network path. ... ReadDirectoryChangesW API. ... Heavy-weight solutions would be to write a dedicated file system filter ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Writing to beginning of file?
    ... a problem of file system. ... the complexities up to the applications or the libraries used by the ... Read into this second buffer the beginning of the file. ...
    (comp.unix.programmer)
  • Re: [PATCH] jbd: dont abort if flushing file data failed
    ... buffer has an error. ... data to the disk, should we not mark the file system readonly by aborting ... If we make the file system read-only on a file data write error, ... So some people need this patch. ...
    (Linux-Kernel)
  • Re: sequential vs. random
    ... I/O BUFFER - assembles BLOCK according to the number of 128byte ... file into the number of the 128byte CP/M ... limited value in using CP/M's random access calls unless the database ... CP/M disk systems had no universal standard for  physical record ...
    (comp.os.cpm)