Re: Programming in standard c

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. Maybe there is SOMEWHERE in
the world a crazy file system like that but why should we
care about it?

If you don't care about portability to those
platforms, there's no reason why you can't use OS-specific techniques
for determining the file length.


Much simpler would be if we had

size_t filesize(FILE *);

isn't it?

I.e. the standard would abstract away from the programmer all the
details of how to do this quite ELEMENTARY operation!

If there are file systems where there is no way to know that besides
by reading the whole file, then THOSE SYSTEMS would be forced to do that
not everyone!


If you use that approach, there's no need to worry about how lines are
terminated for any particular implementation, whether with CR, LF,
CRLF, LFCR, or by padding the lines with null characters to the end of
a fixed maximum line size, or any other method that an implementation
finds ocnvev


THAT could be left to the implementation of "filesize" and we
could rely on a portable way of doing that. The objective of this
message is precisely to point to the lack of functionality in
the standard library.

3) I used different values for errno defined by POSIX, but not by

I saw no reason why, at any point, your program should set errno to
any value other than whichever one the underlying C standard library
functions would have already set it to. If fopen() doesn't already set
ENOENT, why should strfromfile()? If fseek() doesn't already set EIO,
why should strfromfile()? If malloc() doesn't already set ENOMEM, why
should strfromfile()? Don't make things harder than they have to be;
even if strfromfile() were standardized, I'd still recommend that the
implementor piggy-back off the lower level functions it calls, rather
than setting it's own error codes.

I *had* to do this since there is NOW no guarantee that the lower level
functions do this. I was programming around a limitation of standard C.

I do not understand why the committee ignores all the work done by POSIX
and incorporates their error analysis into standard C for the low level
functions like fread/fopen, etc.

Why refusing to do a more sophisticated error analysis than just testing
for NULL?

I cite the standard for the fopen function:
Returns
The fopen function returns a pointer to the object controlling the
stream. If the open operation fails, fopen returns a null pointer.

Not a SINGLE WORD of error analysis more sophisticated than

"it failed".

This is really level ZERO of error analysis.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
.

Relevant Pages

  • Re: Programming in standard c
    ... by POSIX and incorporates their error analysis into standard C ...
    (comp.lang.c)
  • Re: Programming in standard c
    ... I.e. the standard would abstract away from the programmer all the ... I *had* to do this since there is NOW no guarantee that the lower level ... I was programming around a limitation of standard C. ... Why refusing to do a more sophisticated error analysis than just testing ...
    (comp.lang.c)
  • Re: C, really portable?
    ... > The result of printf is negative if there was an error, ... > The standard makes NO error analysis, ... > could have been a single value, specified by the standard ... But the reality is that printfhardly ever fails, ...
    (comp.lang.c)
Quantcast