Re: Programming in standard c

user923005 <dcorbit@xxxxxxxxx> writes:

On Dec 27, 3:26 pm, jacob navia <ja...@xxxxxxxxxx> wrote:
Richard Heathfield wrote:
jacob navia said:

<snip>

This insistence of getting the WORST system then FORCING all other
people to adapt themselves to that pile of sh...!

No, nobody insists on any such thing, and nobody is forcing anyone to do
anything. If you want a system-specific solution, you can have one,
because implementors provide them for such tasks as getting the file size
in a way meaningful on the system they are targeting. But those who need a
truly portable solution are not able to make the kinds of assumptions that
you seem to think are reasonable. You may have the luxury of choosing the
hardware you will target, but not everyone else has that luxury. You might
be able to say "I wouldn't be seen dead using such a stupid system", but
other people do have to use systems that you wouldn't be seen dead using.
C does not abandon them.

This is exactly the levelling by the worst.

Of course "C does not abandon them". They have just to
1) open the file
2) Read until they hit...
3) EOF!

Imagine a Z/OS machine with a 1000 GB file. Do you know how much this
operation will cost and how long it will take?

Then they have the file size. PERIOD. Nothing is "abandoned".

Then the file size changes one microsecond later. What do they do
with this very expensive measurement that they have made?

How ridiculous. This is true for many things. Always "file size" in
"portable C" is useless. This is what Jacob is alluding to.

But we could rely on a PORTABLE function to do that instead of
using zig different functions.

Perhaps a system specific function can do a much better job. Perhaps

You seem to miss the point. filesize(fp) is portable if it's in the
standard. How it is implemented per platform is another issue.

a generic function cannot produce a reliable answer. I guess that
other people have thought about this question and figured out that a
reliable file size function cannot be written in a generic manner.

Rubbish. All files have a byte size. And the "size" returned for a
specific platform will be well documented with regard to padding bytes
or whatever.


What is funny is that precisely the same people that always
get their mouth full of "PORTABILITY IS ALL IMPORTANT"

No. Portability is very important for the part of the code that can
be made portable. But getting the job done is very important so it is
sometimes a requirement to use something that is not part of any
standard.

now argue that improving C by giving more portable functions
is "impossible".

Noone has ever said this. A portable file size function that gives a
correct answer is clearly impossible.

How silly.

"correct" would be platform specific. The API need not be.
.

Relevant Pages

  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> tolower() is implemented. ... >> platform, without even having to know which character set is used on that ... is, however, an error in portability for me to *call* that macro. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)
  • Re: C portability is a myth
    ... Of course it was the C standard itself which was ... I did not even think about portability. ... platform, all compliant with the exact same version of the ANSI C ... its a limiting factor on availability. ...
    (comp.lang.c)
  • Re: removing a loop cause it to go at half the speed?
    ... The concepts are also useful because they are well defined by the same standard that defined the C language. ... If the standard says it is undefined behaviour then even if your implementation defines it you know that you will have to check whether it is documented for *every* system you want to use it on in the future, and you may well come across a system which leaves it completely undefined and possibly even causes random behaviour. ... or you will have on some other platform. ... Portability is not always easy or possible, but the starting point is knowing what the C standard guarantees and what it doesn't. ...
    (comp.lang.c)
  • Re: C portability is a myth
    ... Of course it was the C standard itself which was ... I did not even think about portability. ... >> other C compilers that follow the standard. ... > to the portability is going to be the capabilities of that platform. ...
    (comp.lang.c)