Re: Programming in standard c

user923005 wrote:
On Dec 26, 2:12 pm, jacob navia <ja...@xxxxxxxxxx> wrote:
jameskuy...@xxxxxxxxxxx wrote:
jacob navia wrote:
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?

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.

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?

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.

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!

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?

:-)


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?


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!


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

Relevant Pages

  • Re: IFS Recess
    ... The new jpeg standard rejected fractal compression in favor of other ... it was appropriate to revisit the lossless coding mode within JPEG. ... This mode had been a late addition to the standard, ... A number of contenders for a suitable algorithm were proposed, ...
    (sci.fractals)
  • Re: Why Lisp is not popular with average programmers
    ... to fail to explain how to put up a standard GUI, or at the very least link to the C libraries that do. ... Or are you talking about some other language standard which lets you ... language the operating system is written in. ...
    (comp.lang.lisp)
  • Re: Getting the "program name"
    ... > - Tell us your compiler and operating system ... I'm trying to improve our standard error routine, ...
    (comp.lang.cobol)
  • Re: interface
    ... Writing portable code has nothing to do with the operating system or ... independent of which operating system you are using. ... presented by the programming language and it's standard library. ... platform. ...
    (comp.programming)
  • Re: CFAN (was: A small wildcard matching algorithm)
    ... of files and then treat them as if they are separate files, ... a standard directory wordset without having to standardise. ... Disadvantages -- No compression unless we include compression. ... I know pretty usable system without files and pipes. ...
    (comp.lang.forth)