Programming in standard c

[jacob navia]

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.

1 I read the file contents in binary mode, what should allow me
to use ftell/fseek to determine the file size.

No objections to this were raised, except of course the obvious
one, if the "file" was some file associated with stdin, for
instance under some unix machine /dev/tty01 or similar...

I did not test for this since it is impossible in standard C:
isatty() is not in the standard.

2) There is NO portable way to determine which characters should be
ignored when transforming a binary file into a text file. One
reader (CB Falconer) proposed to open the file in binary mode
and then in text mode and compare the two buffers to see which
characters were missing... Well, that would be too expensive.

3) I used different values for errno defined by POSIX, but not by
the C standard, that defines only a few. Again, error handling
is not something important to be standardized, according to
the committee. errno is there but its usage is absolutely
not portable at all and goes immediately beyond what standard C
offers.

We hear again and again that this group is about standard C *"ONLY"*.
Could someone here then, tell me how this simple program could be
written in standard C?

This confirms my arguments about the need to improve the quality
of the standard library!

You can't do *anything* in just standard C.

 

[Walter Roberson]

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.

1 I read the file contents in binary mode, what should allow me
to use ftell/fseek to determine the file size.

No objections to this were raised, except of course the obvious
one, if the "file" was some file associated with stdin, for
instance under some unix machine /dev/tty01 or similar...

Binary files may read with an indeterminate number of extra binary
0's at the end of them.

 

[Walter Roberson]

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.

2) There is NO portable way to determine which characters should be
ignored when transforming a binary file into a text file. One
reader (CB Falconer) proposed to open the file in binary mode
and then in text mode and compare the two buffers to see which
characters were missing... Well, that would be too expensive.

tmpnam() to get a temporary file name; write something short to the file
in one mode, freopen() the file in the other mode (making sure
you don't clobber the contents), then see what is read in.

 

[Flash Gordon]

jacob navia wrote, On 26/12/07 20:54:

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.

Incorrect. It was shown that YOU failed to do it, not that it cannot be
done. A simple modification of Chuck's ggets would probably do the job
(remove the termination on EOL and let it run to EOF instead).

1 I read the file contents in binary mode, what should allow me
to use ftell/fseek to determine the file size.

No objections to this were raised, except of course the obvious
one, if the "file" was some file associated with stdin, for
instance under some unix machine /dev/tty01 or similar...

Incorrect, I also pointed out that it would fail on WINDOWS with a ^Z
terminated text file and that the C standard does not guarantee that you
can seek to the end of a binary file at all.

I did not test for this since it is impossible in standard C:
isatty() is not in the standard.

There are ways to achieve the stated aim that do not involve finding the
length in advance.

2) There is NO portable way to determine which characters should be
ignored when transforming a binary file into a text file. One

True but irrelevant to solving the problem properly.

reader (CB Falconer) proposed to open the file in binary mode
and then in text mode and compare the two buffers to see which
characters were missing... Well, that would be too expensive.

So use the simple method, i.e. the one C provides, and open the file in
text mode.

3) I used different values for errno defined by POSIX, but not by
the C standard, that defines only a few. Again, error handling
is not something important to be standardized, according to
the committee. errno is there but its usage is absolutely
not portable at all and goes immediately beyond what standard C
offers.

No, *your* usage of it is not portable.

We hear again and again that this group is about standard C *"ONLY"*.
Could someone here then, tell me how this simple program could be
written in standard C?

See above.

This confirms my arguments about the need to improve the quality
of the standard library!

No, it shows that you do not know how to use the standard C library to
solve your problem and that is a different thing entirely.

You can't do *anything* in just standard C.

Oh, *I* can do things in standard C, I can also do things using
extensions where it is appropriate, and I can mix the two as I choose.
The same seems to apply to some of the others here.

Now, personally I cannot be bothered to modify Chuck's code to solve
your problem, however any competent C programmer should find the task
easy enough. I could also write a function to do it myself easily.
However, I'm fundamentally lazy and cannot be bothered to dig out
Chuck's code and modify it to meet a need I do not have.

 

[jameskuyper]

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.

 

[Eric Sosman]

[...]
You can't do *anything* in just standard C.

Then why do you bother with this newsgroup? Why do
you waste your time on a powerless language? Why don't
you go away and become a regular on comp.lang.mumps or
comp.lang.apl or any newsgroup devoted to a language you
consider more useful than C? Since C has zero utility
(in your stated estimation), even comp.lang.cobol would
be a forum of more value. Go! Spend your talent on
something more useful than the torment of us poor old
dinosaurs! Go!

 

[Richard]

[...]
You can't do *anything* in just standard C.

Then why do you bother with this newsgroup? Why do
you waste your time on a powerless language? Why don't
you go away and become a regular on comp.lang.mumps or
comp.lang.apl or any newsgroup devoted to a language you
consider more useful than C? Since C has zero utility
(in your stated estimation), even comp.lang.cobol would

No. real C has lots of uses. You know : the reason this group was
founded. For C programmers to discuss real world C situations.

 

[user923005]

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.

I think you do not understand what it means to "prove" something.
You cannot hold up a white duck and declare that all ducks are
therefore white.

1 I read the file contents in binary mode, what should allow me
   to use ftell/fseek to determine the file size.

   No objections to this were raised, except of course the obvious
   one, if the "file" was some file associated with stdin, for
   instance under some unix machine /dev/tty01 or similar...

   I did not test for this since it is impossible in standard C:
   isatty() is not in the standard.

It might be nice to add some POSIX functions to standard C.
Microsoft offers _isatty() as an extension, but it obviously does not
share the POSIX name exactly.
I guess that almost every compiler vendor that offers a compiler for
which machines may have a TTY type device attached have some way to
detect it as an extension.
However, there is no standard way to do that, as you have pointed out.
Of course, you can accomplish it anyway.

I guess that your argument is that we need to add isatty() to the
language. It might be a good idea.

2) There is NO portable way to determine which characters should be
    ignored when transforming a binary file into a text file. One
    reader (CB Falconer) proposed to open the file in binary mode
    and then in text mode and compare the two buffers to see which
    characters were missing... Well, that would be too expensive.

Is the original file on an EBCDIC machine? Is the original file
UNICODE characters? How about UTF-8, with some of the long 4-byte
Chinese characters in it? Is it an executable for a SUN platform? Is
it a SPICE file containing electronic circuits?

The kinds of things we might want to do to transform a data file
depend utterly on the kind of data that the file contains.

3) I used different values for errno defined by POSIX, but not by
    the C standard, that defines only a few. Again, error handling
    is not something important to be standardized, according to
    the committee. errno is there but its usage is absolutely
    not portable at all and goes immediately beyond what standard C
    offers.

If there is an exception reading the file, an error will be signaled
and errno will contain the meaning. If you do not understand what the
number means, then you can use strerror().

We hear again and again that this group is about standard C *"ONLY"*.
Could someone here then, tell me how this simple program could be
written in standard C?

The premise is that the program is simple. A simple program to read
any possible binary image and perform appropriate transformations on
it? I think that this might be the most complex program imaginable.
Will your program be able to handle a relative file? Will your
program understand the indexes on an RMS file? Will your program
understand a KSDS, ESDS or RRDS data set on an IBM mainframe? How can
we make this truly generic? (I'm all ears, by the way and I'm not
joking about that). I work at a database middleware company. Right
now, we support around 600 distinct data types for our customers. Our
market is but a fraction of all possible customers in the world. I
guess that the things you might find in a binary file are practically
without number. If you can find a simple way to process any binary
file and do something meaningful with its contents, then you will have
a marvelous product indeed.

Let's not forget about the question that has gone unasked here: "How
big is memory?"

This confirms my arguments about the need to improve the quality
of the standard library!

I do not think you are talking about improving the quality of the
standard library. You are talking about adding functions to it.
Those two things are different (and both laudable) goals.

Some of the added functionality you describe is almost always present
in vendor libraries or libraries related to other standards like
POSIX. However, I agree that adding such functionality to the
language itself might be a good thing, if you can get all of the
compiler vendors to agree on it. On the other hand, I think that {for
instance} garbage collection does not belong in C (It causes me no end
of problems in the languages that I have to use that contain it, and I
don't even rely on them for speed). And so if GC gets added to the
language, it would pretty well kill C for me for any practical
purposes. Now, it might not mean destruction of the language for
other people. But I would at least want a faucet to be able to turn
it off (and I mean *all the way* off -- so that it could not sneak in
via an external library).

You can't do *anything* in just standard C.

Depend on who 'You' is.

Your argument is:
"You cannot do task X in just standard C, therefore you cannot do
anything in just standard C"
You have not proven anything except that task X will require something
outside the standard. There are lots of large projects that have been
written in portable, standard C. And there are many large projects
where *most* of the project is in portable, standard C and small sub-
folders are added to account for different operating systems.
I suspect that the task you propose will still be incredibly
difficult, even with a one billion dollar effort to extend the
functions offered by the standard.

Here are some efforts for portable reading of files:
http://cdf.gsfc.nasa.gov/
http://www.unidata.ucar.edu/software/netcdf/
http://www.ncl.ucar.edu/Document/Manuals/Ref_Manual/NclFormatSupport.shtml

Of course, such efforts fall far short of abstract file manipulation
that works in a general way.
I think your question is on par with: 'Will the turing machine
halt?'. Of course, it is quite likely that I simply do not understand
your proposal at all.

 

[jacob navia]

[...]
You can't do *anything* in just standard C.

Then why do you bother with this newsgroup? Why do
you waste your time on a powerless language? Why don't
you go away and become a regular on comp.lang.mumps or
comp.lang.apl or any newsgroup devoted to a language you
consider more useful than C? Since C has zero utility
(in your stated estimation), even comp.lang.cobol would
be a forum of more value. Go! Spend your talent on
something more useful than the torment of us poor old
dinosaurs! Go!

Stop whining and see the sentence in my message:
<quote>
This confirms my arguments about the need to improve the quality
of the standard library!
<end quote>

The solution for me is to improve what is there.

For you is just "go away" "go to another language" and similar
nonsense.

Every time I point out something that needs to be improved
the regulars are unable to put any coherent argumentation.
look at that:

> Why don't
> you go away and become a regular on comp.lang.mumps or
> comp.lang.apl or any newsgroup devoted to a language you
> consider more useful than C? Since C has zero utility
> (in your stated estimation), even comp.lang.cobol would
> be a forum of more value. Go! Spend your talent on
> something more useful than the torment of us poor old
> dinosaurs! Go!
>

Not even the shadow of an argumentation of WHY things
should STAY as they are.

 

[Julienne Walker]

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.

1 I read the file contents in binary mode, what should allow me
to use ftell/fseek to determine the file size.

No objections to this were raised, except of course the obvious
one, if the "file" was some file associated with stdin, for
instance under some unix machine /dev/tty01 or similar...

I did not test for this since it is impossible in standard C:
isatty() is not in the standard.

2) There is NO portable way to determine which characters should be
ignored when transforming a binary file into a text file. One
reader (CB Falconer) proposed to open the file in binary mode
and then in text mode and compare the two buffers to see which
characters were missing... Well, that would be too expensive.

Would building the buffer as you go be too expensive too? Personally,
I was wondering why you went to the trouble of even *trying* to
transform a binary file into a text file. Why not simply take a FILE
pointer and let the caller worry about the file mode? Then instead of
the clearly non-portable method of getting a file size, use a
reasonably efficient buffering technique and read the file
sequentially. That solves issues 1 and 2 quite nicely.

3) I used different values for errno defined by POSIX, but not by
the C standard, that defines only a few. Again, error handling
is not something important to be standardized, according to
the committee. errno is there but its usage is absolutely
not portable at all and goes immediately beyond what standard C
offers.

Then don't use it? It's not like you're barred from writing your own
error handling mechanism, and fortunately you're also not forced to
follow the conventions of the standard library. I see a lot of self-
imposed restrictions in that attempt (no offense), and if you remove
them, I don't think your current claim holds water.

We hear again and again that this group is about standard C *"ONLY"*.
Could someone here then, tell me how this simple program could be
written in standard C?

Here's a prototype:

#include <stdio.h>
#include <stdlib.h>

char *readall ( FILE *in, int *n )
{
char *result = NULL;
size_t size = 0;
int curr = 0;
int ch;

while ( ( ch = fgetc ( in ) ) != EOF ) {
if ( curr == size ) {
char *save = realloc ( result, size + BUFSIZ + 1 );

if ( save == NULL )
break;

result = save;
size += BUFSIZ;
}

result[curr++] = (char)ch;
}

*n = curr;

return result;
}

It's fairly naive for a start, but with more detailed requirements I
still don't see how it can't be done in standard C.

This confirms my arguments about the need to improve the quality
of the standard library!

I agree that the standard library needs work, but I don't agree that
this is one of the things that it needs. You'll need to convince me a
little more.

You can't do *anything* in just standard C.

Excepting any silly mistakes in my code, I'd say that your claim is
false.

 

[Eric Sosman]

[...]
You can't do *anything* in just standard C.

Then why do you bother with this newsgroup? Why do
you waste your time on a powerless language? Why don't
you go away and become a regular on comp.lang.mumps or
comp.lang.apl or any newsgroup devoted to a language you
consider more useful than C? Since C has zero utility
(in your stated estimation), even comp.lang.cobol would
be a forum of more value. Go! Spend your talent on
something more useful than the torment of us poor old
dinosaurs! Go!

Stop whining and see the sentence in my message:
<quote>
This confirms my arguments about the need to improve the quality
of the standard library!
<end quote>

You wrote: "You can't do *anything* in just standard C."
Do you stand by that statement, or do you retreat from it?
If you stand by it, why are you here?

 

[jacob navia]

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.

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.

 

[user923005]

[...]
You can't do *anything* in just standard C.

    Then why do you bother with this newsgroup?  Why do
you waste your time on a powerless language?  Why don't
you go away and become a regular on comp.lang.mumps or
comp.lang.apl or any newsgroup devoted to a language you
consider more useful than C?  Since C has zero utility
(in your stated estimation), even comp.lang.cobol would
be a forum of more value.  Go!  Spend your talent on
something more useful than the torment of us poor old
dinosaurs!  Go!

Stop whining and see the sentence in my message:
<quote>
This confirms my arguments about the need to improve the quality
of the standard library!
<end quote>

The solution for me is to improve what is there.

For you is just "go away" "go to another language" and similar
nonsense.

Every time I point out something that needs to be improved
the regulars are unable to put any coherent argumentation.
look at that:

 > Why don't
 > you go away and become a regular on comp.lang.mumps or
 > comp.lang.apl or any newsgroup devoted to a language you
 > consider more useful than C?  Since C has zero utility
 > (in your stated estimation), even comp.lang.cobol would
 > be a forum of more value.  Go!  Spend your talent on
 > something more useful than the torment of us poor old
 > dinosaurs!  Go!
 >

Not even the shadow of an argumentation of WHY things
should STAY as they are.

When you act in an inflamatory way, surely you expect an inflamatory
response.
Of course, the game would not be nearly so fun if we all talked to
each other in a civil manner. But that would assume that we actually
wanted to *make* progress.

 

[jacob navia]

Would building the buffer as you go be too expensive too? Personally,
I was wondering why you went to the trouble of even *trying* to
transform a binary file into a text file. Why not simply take a FILE
pointer and let the caller worry about the file mode? Then instead of
the clearly non-portable method of getting a file size, use a
reasonably efficient buffering technique and read the file
sequentially. That solves issues 1 and 2 quite nicely.

If you reduce the requirements of course, it is easy...
But then the usage of your utility is greatly reduced.

Then don't use it? It's not like you're barred from writing your own
error handling mechanism, and fortunately you're also not forced to
follow the conventions of the standard library. I see a lot of self-
imposed restrictions in that attempt (no offense), and if you remove
them, I don't think your current claim holds water.

But the point is that that error mechanism wouldn't be standard.

I do not want to argue trhat it is impossible to write this program
in C. I am arguing that it is not possible to write it in STANDARD C.

We hear again and again that this group is about standard C *"ONLY"*.
Could someone here then, tell me how this simple program could be
written in standard C?

Here's a prototype:

#include <stdio.h>
#include <stdlib.h>

char *readall ( FILE *in, int *n )
{
char *result = NULL;
size_t size = 0;
int curr = 0;
int ch;

while ( ( ch = fgetc ( in ) ) != EOF ) {
if ( curr == size ) {
char *save = realloc ( result, size + BUFSIZ + 1 );

if ( save == NULL )
break;

result = save;
size += BUFSIZ;
}

result[curr++] = (char)ch;
}

*n = curr;

return result;
}

It's fairly naive for a start, but with more detailed requirements I
still don't see how it can't be done in standard C.

1) You suppose that the file pointer is at the beginning of the file
To be sure you should to an fseek before reading...
2) You allocate always in BUFSIZE chunks, and you have an almost 100%
probability of wasting memory.
3) If you run out of memory you return a truncated file, giving the user
NO WAY to know that the data is missing!
4) The string is not zero terminated... You write the EOF value at the
end in most cases.

Look, all those bugs can be easily corrected and your approach is maybe
sounder than mine. You will agree however, that

fpos_t filesize(FILE *);

would be useful isn't it?

I agree that the standard library needs work, but I don't agree that
this is one of the things that it needs. You'll need to convince me a
little more.


Excepting any silly mistakes in my code, I'd say that your claim is
false.

You took down the most important use of this utility:
Abstracting away the difference from binary/text files
from the user. If we take that away, it would be useful only
for binary files.

Thanks for your input.

 

[user923005]

er... YES!


We could restrict this to normal files.

Do you understand that 'normal' files behave in completely different
ways, depending on what kind of files they are?
On OpenVMS, for instance, there are sequential files, indexed files,
and relative files. The files can be compressed, and (if indexed) the
indexes can be compressed. This compression can be partial or total.
How will your "simple" functions deal with this one complexity on a
single OS?

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?

The best you can ever hope for is an estimate. On the RMS example
from above, if you have a compressed file, it might be very tiny but
contain a million records. So will knowing the size of the file give
you meaningful information about what it contains?

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!

You do understand that this operation has no real meaning on a multi-
user system?

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!

For systems where we would have to special-case things, we will need
'one-off' functions to handle it. Do these functions belong in the
standard? BTW, the systems where we have to special case things is
"almost all of them."[*]

[*] my informal estimate, based on experience but not measured.

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.

Please describe how this portable 'filesize' function works just on a
system 3090. If it does not work there, will the compiler vendors
want to implement it? If the compiler vendors do not want to
implement it, shall we add it to the standard?

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.

That is more than zero.

Do you understand that operating system X can return errors that do
not exist on operating system Y?

 

[CBFalconer]

.... snip ...

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.

Yes. Read your own quote above and ponder it for a while. As you
come up with reasons write them down. After you have twenty
written, come back here.

 

[jacob navia]

Do you understand that 'normal' files behave in completely different
ways, depending on what kind of files they are?

Who cares?

The C implementation ALREADY abstracts that away from us.

I know that I can open a file for writing under OpenVMS
or whatever and I can write two bytes in it and read them again.

SO FAR the abstraction works. What I am proposing is just a
bit more of FUNCTIONALITY.

On OpenVMS, for instance, there are sequential files, indexed files,
and relative files. The files can be compressed, and (if indexed) the
indexes can be compressed. This compression can be partial or total.
How will your "simple" functions deal with this one complexity on a
single OS?

In the same manner that fopen abstract all that away from
me.

The best you can ever hope for is an estimate. On the RMS example
from above, if you have a compressed file, it might be very tiny but
contain a million records. So will knowing the size of the file give
you meaningful information about what it contains?

The value returned should be equivalent to the bytes that I would read
in binary mode.

You do understand that this operation has no real meaning on a multi-
user system?

Ah well. I am dreaming then all the time.

I write

dir

and the multi-user file system tells me the size of each file.

ANd in unix I do

ls

and (WONDER) I get a meaningless result with the file size of
each file.

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!

For systems where we would have to special-case things, we will need
'one-off' functions to handle it. Do these functions belong in the
standard? BTW, the systems where we have to special case things is
"almost all of them."[*]

If we define filesize as the number of bytes that would
be returned when reading the file we do not have to special case
anything.

But granted, a binary/text mode would be nice.

Please describe how this portable 'filesize' function works just on a
system 3090. If it does not work there, will the compiler vendors
want to implement it? If the compiler vendors do not want to
implement it, shall we add it to the standard?

In system 3090 it returns the size of the file. Even in that system,
I can see the size of each file.

But you are surely a bit of outmoded I would say.

According to IBM, you can easily upgrade your system 3090 to a system
9000.

Only thing is that system 9000 was introduced in 1990 (so system 3090
must be a mainframe of 198x!). Even system 9000 doesn't exist anymore,
since IBM retired it in 1998...

You search for VERY current examples isn't it?

That is more than zero.

Do you understand that operating system X can return errors that do
not exist on operating system Y?

So what?

If a mapping from the native error to the given error palette is not
possible, the implementation can return that error code!

But we could PORTABLY test for IO errors, "no memory" errors, etc!

 

[CBFalconer]

.... snip ...

But the point is that that error mechanism wouldn't be standard.

I do not want to argue trhat it is impossible to write this program
in C. I am arguing that it is not possible to write it in STANDARD C.

I believe 'this program' has to read in a file of text lines, and
store it in a buffer. I can do that in standard C. Do you want it
broken into lines, or just one solid string?

It will also work if the input file is stdin. However, it will not
work if you exceed the limits of the machine on which it runs.

How much are you willing to pay me for the source?

 

[jacob navia]

You wrote: "You can't do *anything* in just standard C."
Do you stand by that statement, or do you retreat from it?
If you stand by it, why are you here?

int main(void) { int n = printf("hello\n");}
How much is n?

No way to know since the error codes of printf
are NOT standardized. This means that I can only
know that n can be... *ANYTHING*. Maybe it wrote
some characters, then stopped, or whatever!

The problem with the lack of standardization of error codes
means that I can't do error checking in a portable way
and thus, no portable program of any importance can be
written that handles the different error situations that
could arise.

In normal software, you *are* interested into why this program/function
call failed. You can't portably do that in standard C;

You can't even know the size of a file without reading it all.

A bit of more functionality would be better for all of us. But
if I am in this group obviously, it is not because I
believe standard C is useless but because I want to fix some
problems with it.

Does this answer your question?

 

[Bart C]

I've been using a function like the following:

unsigned int getfilesize(FILE* handle)
{
unsigned int p,size;
p=ftell(handle); /*p=current position*/
fseek(handle,0,2); /*get eof position*/
size=ftell(handle); /*size in bytes*/
fseek(handle,p,0); /*restore file position*/
return size;
}

What is wrong with this, is it non-standard? (Apart from the likely 4Gb
limit)

You do understand that this operation has no real meaning on a multi-
user system?

Because anything could happen between getting the size and making use of it?
In that case pretty much everything is impossible.

and relative files. The files can be compressed, and (if indexed) the
indexes can be compressed. This compression can be partial or total.
How will your "simple" functions deal with this one complexity on a
single OS?

So the file is compressed, so what? If the compression is made transparent
by the OS, I will get the full filesize. If not, will get the size of a
compressed file. The compression is likely irrelevant, and I can't do
anything with it anyway. And if I can, I will know how to decompress and how
to get the inflated size.

Someone mentioned streams in this thread, but on my computer as an example,
I have so many hundred thousand files 99.99...% of which are just a bunch of
so many bytes. This type of 'File' seems so dominant that surely it should
have been given special treatment apart from streams.

Bart