«

Why are C interfaces so low level?

We discussed a bit about this in the thread about getting an URL from
the internet.

Take, for instance, we all some day needed to read an entire
file into RAM to process it. Why there isn't

char *strfromfile(const char *file_name,const char *mode);

As a holidays present, here it is.

#include <string.h>
#include >errno.h>
#include <stdio.h>
#include <stdlib.h>
char *strfromfile(const char *fname,const char *mode)
{
if (fname == NULL || mode == NULL) {
errno = EINVAL;
return NULL;
}
FILE *f = fopen(fname,"rb");
if (f == NULL) {
errno = ENOENT;
return NULL;
}
if (fseek(f,0,SEEK_END) != 0) {
ioerror:
errno = EIO; // IO error
fclose(f);
return NULL;
}
long l = ftell(f);
if (l < 0) goto ioerror;
if (fseek(f,0,SEEK_SET) != 0)
goto ioerror;
char *result = malloc(l+1);
if (result == NULL) {
errno = ENOMEM;
fclose(f);
return NULL;
}
if (fread(result,1,l,f) <= 0)
goto ioerror;
result[l] = 0;
fclose(f);
if (strchr(mode,'b') == NULL) {
char *src = result,*dst = result;
while ((src - result) < l) {
if (*src != '\r')
*dst++ = *src;
src++;
}
*dst = 0;
}
return result;
}

Argument "mode" should be either "r" or "rb" for binary or text mode.
This can be omitted in Unix systems, where this stupid distinction
doesn't exist.

If I do not find a "b" in the "mode" string I eliminate CRs from the
string.

NOTE: This function will not run in the DS9000
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> #include >errno.h>

That should have been
#include <errno.h>

obviously.

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

jacob navia wrote:
> Why are C interfaces so low level?
>
> We discussed a bit about this in the thread about getting an URL from
> the internet.
>
> Take, for instance, we all some day needed to read an entire
> file into RAM to process it. Why there isn't
>
> char *strfromfile(const char *file_name,const char *mode);
>
> As a holidays present, here it is.
>
> #include <string.h>
> #include >errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> char *strfromfile(const char *fname,const char *mode)
> {
> if (fname == NULL || mode == NULL) {
> errno = EINVAL;
> return NULL;
> }
> FILE *f = fopen(fname,"rb");
> if (f == NULL) {
> errno = ENOENT;
> return NULL;
> }
> if (fseek(f,0,SEEK_END) != 0) {
> ioerror:
> errno = EIO; // IO error
> fclose(f);
> return NULL;
> }
> long l = ftell(f);
> if (l < 0) goto ioerror;
> if (fseek(f,0,SEEK_SET) != 0)
> goto ioerror;
> char *result = malloc(l+1);
> if (result == NULL) {
> errno = ENOMEM;
> fclose(f);
> return NULL;
> }
> if (fread(result,1,l,f) <= 0)
> goto ioerror;
> result[l] = 0;
> fclose(f);
> if (strchr(mode,'b') == NULL) {
> char *src = result,*dst = result;
> while ((src - result) < l) {
> if (*src != '\r')
> *dst++ = *src;
> src++;
> }
> *dst = 0;
> }
> return result;
> }
>
> Argument "mode" should be either "r" or "rb" for binary or text mode.
> This can be omitted in Unix systems, where this stupid distinction
> doesn't exist.
>
> If I do not find a "b" in the "mode" string I eliminate CRs from the
> string.
>
What string? Files don't (usually) have strings. They have lines.

What do you do about the SUB character (if you find one) ?

Merry Christmas.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

jacob navia wrote, On 24/12/07 23:37:
> Why are C interfaces so low level?
>
> We discussed a bit about this in the thread about getting an URL from
> the internet.

In general the more flexible the library the more complex the interface.

> Take, for instance, we all some day needed to read an entire
> file into RAM to process it.

I haven't so far. At least, not in to one string.

> Why there isn't
>
> char *strfromfile(const char *file_name,const char *mode);
>
> As a holidays present, here it is.
>
> #include <string.h>
> #include >errno.h>

You corrected this mistake in a follow up.

> #include <stdio.h>
> #include <stdlib.h>
> char *strfromfile(const char *fname,const char *mode)
> {
> if (fname == NULL || mode == NULL) {
> errno = EINVAL;
> return NULL;
> }
> FILE *f = fopen(fname,"rb");

Wouldn't it be more sensible to use the mode the user passes in?

> if (f == NULL) {
> errno = ENOENT;
> return NULL;
> }
> if (fseek(f,0,SEEK_END) != 0) {
> ioerror:
> errno = EIO; // IO error
> fclose(f);
> return NULL;
> }
> long l = ftell(f);
> if (l < 0) goto ioerror;
> if (fseek(f,0,SEEK_SET) != 0)

This is not a portable method of determining file size. Mainly because
there is o portable method. You should at least comment the
non-portabilities.

> goto ioerror;
> char *result = malloc(l+1);
> if (result == NULL) {
> errno = ENOMEM;
> fclose(f);
> return NULL;
> }
> if (fread(result,1,l,f) <= 0)

Using l as a variable name was a bad idea because it makes it harder to
read the above line, or easier to miss-read it.

Also you fail to allow for it reading fewer then the number of 1 byte
members you specify. This can happen for a number of reasons.

> goto ioerror;
> result[l] = 0;
> fclose(f);
> if (strchr(mode,'b') == NULL) {
> char *src = result,*dst = result;
> while ((src - result) < l) {

Hmm. You have an initialisation, a test, and an increment, wouldn't a
for loop have been more natural?

> if (*src != '\r')
> *dst++ = *src;
> src++;

Since you have opened the file in binary mode and MacOS 9.x and earlier
use '\r' as the line terminator you have just converted the file to one
long line on some systems.

> }
> *dst = 0;
> }
> return result;
> }
>
> Argument "mode" should be either "r" or "rb" for binary or text mode.
> This can be omitted in Unix systems, where this stupid distinction
> doesn't exist.
>
> If I do not find a "b" in the "mode" string I eliminate CRs from the
> string.
>
> NOTE: This function will not run in the DS9000

You don't need a system that exotic for it to fail.
--
Flash Gordon

On Dec 25, 1:37 am, jacob navia <ja...@nospam.com> wrote:
> Why are C interfaces so low level?
>
> We discussed a bit about this in the thread about getting an URL from
> the internet.
>
> Take, for instance, we all some day needed to read an entire
> file into RAM to process it. Why there isn't
>
> char *strfromfile(const char *file_name,const char *mode);
>
> As a holidays present, here it is.
>
> [ snip ]
> Argument "mode" should be either "r" or "rb" for binary or text mode.
> This can be omitted in Unix systems, where this stupid distinction
> doesn't exist.
>
> If I do not find a "b" in the "mode" string I eliminate CRs from the
> string.
>
> NOTE: This function will not run in the DS9000

Why you never free() what you allocate?
I am talking about this

> ioerror:
> errno = EIO; // IO error
> fclose(f);
> return NULL;
> /* other stuff */
> char *result = malloc(l+1);
> if (result == NULL) {
> errno = ENOMEM;
> fclose(f);
> return NULL;
> }
> if (fread(result,1,l,f) <= 0)
> goto ioerror;
^^^^^^^^^^^^^ At this point memory is allocated and
not freed.

Merry Christmas to the collective of c.l.c!

wrote:

> On Dec 25, 1:37 am, jacob navia <ja...@nospam.com> wrote:
>> Why are C interfaces so low level?
>>
>> We discussed a bit about this in the thread about getting an URL from
>> the internet.
>>
>> Take, for instance, we all some day needed to read an entire
>> file into RAM to process it. Why there isn't
>>
>> char *strfromfile(const char *file_name,const char *mode);
>>
>> As a holidays present, here it is.
>>
>> [ snip ]
>> Argument "mode" should be either "r" or "rb" for binary or text mode.
>> This can be omitted in Unix systems, where this stupid distinction
>> doesn't exist.
>>
>> If I do not find a "b" in the "mode" string I eliminate CRs from the
>> string.
>>
>> NOTE: This function will not run in the DS9000
>
> Why you never free() what you allocate?

<snip>

Because jacob almost always assumes a modern OS like Windows or a UNIX
variant will clean up after the program.

In general, even if the OS may recover the memory, I still prefer
explicitly deallocating them. It better practise and stands up well to
porting to other systems.

On Dec 25, 5:35 am, santosh <santosh....@gmail.com> wrote:
> vipps...@gmail.com wrote:
> > On Dec 25, 1:37 am, jacob navia <ja...@nospam.com> wrote:
> >> Why are C interfaces so low level?
>
> >> We discussed a bit about this in the thread about getting an URL from
> >> the internet.
>
> >> Take, for instance, we all some day needed to read an entire
> >> file into RAM to process it. Why there isn't
>
> >> char *strfromfile(const char *file_name,const char *mode);
>
> >> As a holidays present, here it is.
>
> >> [ snip ]
> >> Argument "mode" should be either "r" or "rb" for binary or text mode.
> >> This can be omitted in Unix systems, where this stupid distinction
> >> doesn't exist.
>
> >> If I do not find a "b" in the "mode" string I eliminate CRs from the
> >> string.
>
> >> NOTE: This function will not run in the DS9000
>
> > Why you never free() what you allocate?
>
> <snip>
>
> Because jacob almost always assumes a modern OS like Windows or a UNIX
> variant will clean up after the program.
>
> In general, even if the OS may recover the memory, I still prefer
> explicitly deallocating them. It better practise and stands up well to
> porting to other systems.


That is silly, Jacob does not care to free his memory but he cares to
close his file streams?

wrote:

> On Dec 25, 5:35 am, santosh <santosh....@gmail.com> wrote:
>> vipps...@gmail.com wrote:
>> > On Dec 25, 1:37 am, jacob navia <ja...@nospam.com> wrote:
>> >> Why are C interfaces so low level?
>>
>> >> We discussed a bit about this in the thread about getting an URL
>> >> from the internet.
>>
>> >> Take, for instance, we all some day needed to read an entire
>> >> file into RAM to process it. Why there isn't
>>
>> >> char *strfromfile(const char *file_name,const char *mode);
>>
>> >> As a holidays present, here it is.
>>
>> >> [ snip ]
>> >> Argument "mode" should be either "r" or "rb" for binary or text
>> >> mode. This can be omitted in Unix systems, where this stupid
>> >> distinction doesn't exist.
>>
>> >> If I do not find a "b" in the "mode" string I eliminate CRs from
>> >> the string.
>>
>> >> NOTE: This function will not run in the DS9000
>>
>> > Why you never free() what you allocate?
>>
>> <snip>
>>
>> Because jacob almost always assumes a modern OS like Windows or a
>> UNIX variant will clean up after the program.
>>
>> In general, even if the OS may recover the memory, I still prefer
>> explicitly deallocating them. It better practise and stands up well
>> to porting to other systems.
>
>
> That is silly, Jacob does not care to free his memory but he cares to
> close his file streams?

I agree. He should treat memory with the same care given to other
resources. Presumably, he feels that data corruption may occur if he
did not explicitly close the streams. That may or may not be true.

jacob navia wrote:
> Why are C interfaces so low level?
>
> We discussed a bit about this in the thread about getting an URL from
> the internet.
>
> Take, for instance, we all some day needed to read an entire
> file into RAM to process it. Why there isn't
>
Because any half decent OS provides a simple means of doing it. C also
runs on plenty of platforms that done have files.

> char *strfromfile(const char *file_name,const char *mode);
>
> As a holidays present, here it is.
>
Been and gone here...

--
Ian Collins.

Ian Collins wrote:

> jacob navia wrote:
>> Why are C interfaces so low level?
>>
>> We discussed a bit about this in the thread about getting an URL from
>> the internet.
>>
>> Take, for instance, we all some day needed to read an entire
>> file into RAM to process it. Why there isn't
>>
> Because any half decent OS provides a simple means of doing it. C
> also runs on plenty of platforms that done have files.

And this particular task is also doable in standard C with no loss in
functionality or efficiency. I understand that the Committee had an
overall policy to include only those new functions in the Standard
library that would be impossible or difficult to replicate in user
code. This is opposite to the philosophy of the C++ Committee.