Re: Programming in standard c

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; but for streams which
correspond to devices, rather than files, there's really no
alternative. 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. 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.

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

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.
.

Relevant Pages

  • Re: NEW_LINE()
    ... I don't recall ever using text streams in my own code. ... standard, then other non-standard extensions (like some kind ... > I/O can still have a record length limit. ... > a line buffer to be written out with a record mark at the end. ...
    (comp.lang.fortran)
  • Re: Great SWT Program
    ... And the emacs term "buffer" is not identical to this. ... Emacs generally doesn't care about your own standard. ... launching "flashlight" is still carrying a concealed gun. ...
    (comp.lang.java.programmer)
  • Re: Buffer overflows and asctime()
    ... to contain a "bug" as others are not. ... standard the year member receives a maximum value. ... will overflow its buffer if confronted with valid inputs. ... So you still do not understand "undefined behavior". ...
    (comp.std.c)
  • Re: Why is it dangerous?
    ... learn that C had such weak string handling, ... Exploiting getson an auto buffer ... that omitted any standard on what could or could not be input. ... the pedants, on whose code contains more *actual* bugs. ...
    (comp.lang.c)
  • Re: read vs fread
    ... fread() and co. is built on top of read, ... >>using the buffer cache with open or fopen. ... The standard C functions usually do some internal buffering, ... are not formatted I/O: we have a unformatted block of one or more bytes. ...
    (comp.os.linux.development.system)