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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Dec 26 '07
270  9187 
jacob navia wrote:
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.
<snip>
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?
It's hardly a surprise that complicated file operations end up
requiring
platform-specific code. Many programs will benefit or require
platform-specific code. The obvious solution is to isolate all of the
non-portable code in your program into a single place, so that when
it comes time to port it to a different platform, only this one module
needs to be rewritten. Your filesize() function is an excellent
candidate for inclusion in this non-standard module.
It's a bad workman who blames his tools: if Standard C isn't the right
tool for a particular job, why not use an appropriate tool rather than
berating Standard C?
Richard Heathfield <rj*@see.sig.invalidwrites:
Most of the C programs I write are ISO C programs. Only a very
small proportion use non-ISO9899 libraries.
If one may inquire, what kind of task do most of your programs
seek to accomplish?
--
Ben Pfaff http://benpfaff.org
Ben Pfaff said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Most of the C programs I write are ISO C programs. Only a very
small proportion use non-ISO9899 libraries.
If one may inquire, what kind of task do most of your programs
seek to accomplish?
It varieth exceeding great, and I'm struggling to pick a form of words that
could briefly and communicatively describe "most" of the programs I write.
At present, however, I'm writing a PHP code generator. In this case, it
happens to be written in ISO C not because it must be, but because I have
no particular need for extensions (why use 'em for the sake of it?).
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia <ja***@nospam.comwrites:
What do I mean with error analysis?
Something like this
FOPEN
[snip]
ERRORS
The fopen() function shall fail if:
[EACCES]
Search permission is denied on a component of the path prefix, or the
file exists and the permissions specified by mode are denied, or the
file does not exist and write permission is denied for the parent
directory of the file to be created.
[EINTR]
A signal was caught during fopen().
[EISDIR]
The named file is a directory and mode requires write access.
[snip]
>
You see?
An implementation would be allowed to extend this errors but we could
portably test for a certain kind of error.
To test if a file does not exist I could test for ENOENT when I try
to open it. I could test EISDIR to see if this file is a directory...
etc etc!
Test and do what? Do you expect a program to behave differently if an
fopen() call fails because the file doesn't exist than if it fails
because it's a directory? Most of the time, I'd expect the program to
print an error message (which is readily available by calling
strerror(errno)) and then doing some generic error handling.
But ok, let's assume you want different behavior beyond just a
differently worded error message. If you know you're on a
POSIX-compliant system, you can go ahead and use all those E* macros.
(POSIX already exists, and is widely supported; I see no need to
incorporate large chunks of it into the C standard, particularly since
C is intended to be supported on a wider variety of underlying
platforms than POSIX is.) Or, if you want both flexibility and
portability, you can do something like this (untested code):
if (... fopen failed ...) {
switch (errno) {
#ifdef EACCES
case EACCES:
/* handle permission error */
break;
#endif
#ifdef EINTR
case EINTR:
/* handle signal error */
break;
#endif
#ifdef EISDIR
case EISDIR:
/* handle directory error */
break;
#endif
default:
/* Unrecognized error; use strerror() to obtain a
message */
break;
}
}
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On 27 Dec 2007 at 18:59, Keith Thompson wrote:
Or, if you want both flexibility and
portability, you can do something like this (untested code):
if (... fopen failed ...) {
switch (errno) {
#ifdef EACCES
case EACCES:
/* handle permission error */
break;
#endif
#ifdef EINTR
case EINTR:
/* handle signal error */
break;
#endif
#ifdef EISDIR
case EISDIR:
/* handle directory error */
break;
#endif
default:
/* Unrecognized error; use strerror() to obtain a
message */
break;
}
}
But if you're not using POSIX, you could define EACCESS etc. as glocal
macros yourself, and then this code could break badly...
jacob navia wrote:
What do I mean with error analysis?
Something like this
FOPEN
[snip]
ERRORS
The fopen() function shall fail if:
[EACCES]
Search permission is denied on a component of the path prefix, or the
file exists and the permissions specified by mode are denied, or the
file does not exist and write permission is denied for the parent
directory of the file to be created.
[EINTR]
A signal was caught during fopen().
[EISDIR]
The named file is a directory and mode requires write access.
[ELOOP]
A loop exists in symbolic links encountered during resolution of the
path argument.
[EMFILE]
{OPEN_MAX} file descriptors are currently open in the calling process.
[ENAMETOOLONG]
The length of the filename argument exceeds {PATH_MAX} or a pathname
component is longer than {NAME_MAX}.
[ENFILE]
The maximum allowable number of files is currently open in the system.
[ENOENT]
A component of filename does not name an existing file or filename is an
empty string.
[ENOSPC]
The directory or file system that would contain the new file cannot be
expanded, the file does not exist, and the file was to be created.
[ENOTDIR]
A component of the path prefix is not a directory.
[ENXIO]
The named file is a character special or block special file, and the
device associated with this special file does not exist.
[EOVERFLOW]
The named file is a regular file and the size of the file cannot be
represented correctly in an object of type off_t.
[EROFS]
The named file resides on a read only file system and write access was
specified.
You see?
An implementation would be allowed to extend this errors but we could
portably test for a certain kind of error.
To test if a file does not exist I could test for ENOENT when I try
to open it. I could test EISDIR to see if this file is a directory...
etc etc!
I repeat the question you snipped and have not yet even
begun to answer:
>What is the appropriate action for "file locked," and how
does it differ from that for "privileges problem?" Portable
actions only, please: you keep talking about portable error
analysis, which is mere mockery without portable error response.
If you like, we can now rephrase it in terms of your list:
For each error code, please explain what "appropriate action"
(your phrase) should be taken, how its action differs from the
actions taken for other codes, and how to take action portably.
Also, do you imagine that the list you exhibit here is an
exhaustive list of failure modes for fopen()? What code should
an implementation use if fopen() fails for lack of memory? What
code reports an incompatibility between the file organization and
C's sequential "stream of bytes" model (c.f. OpenVMS)? What code
is appropriate for a security violation (e.g., low-privilege
program attempting to read a high-privilege file -- note that your
description of EPERM does not cover this case)? What code should
be used if the file name references an environment variable that
has no definition? What code should be used -- ah, the hell with
it. You have not even begun to think about these problems, much
less solve them.
--
Eric Sosman es*****@ieee-dot-org.invalid
jacob navia <ja***@nospam.comwrote:
ja*********@verizon.net wrote:
>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;
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.
Your imagination is obviously not very good.
Take for example CP/M. CP/M only keeps tracks of how many disk-blocks
a file uses. It does not keep track of how many bytes are used in each block.
It is normally the case that the last block of a file has one or more unused bytes.
Under CP/M there is no general way of finding out how many of those bytes are
unused for a given file. For text files the end is marked by a CONTROL-Z (this
was later inherited by MS-DOS). For binary files each program will have to come
up with some way of keeping track of that information inside the data files, or
just accept that there may be some garbage bytes at the end of a file.
Another example would be a file stored on a magnetic tape. There it might not be
possible to find out how large the file is without reading the file until
you reach an end-of-file marker. I am fairly certain that such devices
are still in use.
Maybe there is SOMEWHERE in
the world a crazy file system like that but why should we
care about it?
The world contains many weird file systems and storage devices that are actually
used quite a bit.
--
<Insert your favourite quote here.>
Erik Trulsson er******@student.uu.se
CJ wrote:
On 27 Dec 2007 at 18:59, Keith Thompson wrote:
>Or, if you want both flexibility and
portability, you can do something like this (untested code):
if (... fopen failed ...) {
switch (errno) {
#ifdef EACCES
case EACCES:
/* handle permission error */
break;
#endif
[...]
But if you're not using POSIX, you could define EACCESS etc. as glocal
macros yourself, and then this code could break badly...
Such code is already broken, because Eanything is a
reserved identifier in any file that includes <errno.h>.
See section 7.26.3.
(Well, not "anything," exactly. Any identifier starting
with E and another upper-case letter or starting with E and
a digit is reserved. You can still use identifiers that
begin with E and a lower-case letter or with E and an underscore
or, I guess, with E and a suitable Unicode character, and the
identifier E itself is all right. But EACCESS etc. are reserved,
precisely to avoid the collisions that worry you.)
--
Eric Sosman es*****@ieee-dot-org.invalid
Malcolm McLean wrote, On 27/12/07 16:57:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>Malcolm McLean wrote, On 27/12/07 12:12:
>>>
fseek(fp, 0, SEEK_END);
You should check for success.
>> size = ftell(fp);
Using a method you know is not portable is hardly the best way to
answer Jacob's challenge.
The code is designed to be used in a production environment, and it is
adequate for that.
If you are prepared to limit yourself to environments where things work
as you expect, fine. However, that was NOT the challenge that Jacob posted.
It reads in a MiniBasic script file. If the file is
huge the function will fail, but the interpreter will choke on such an
input anyway.
The file being huge is not the main problem I was commenting on. The
main part I was commenting on was the use of things not guaranteed by
the standard when the challenge was to do it without going beyond the
guarantees of standard C.
--
Flash Gordon
CJ <no****@nospam.invalidwrites:
On 27 Dec 2007 at 18:59, Keith Thompson wrote:
>Or, if you want both flexibility and
portability, you can do something like this (untested code):
if (... fopen failed ...) {
switch (errno) {
#ifdef EACCES
case EACCES:
/* handle permission error */
break;
#endif
[...]
>
But if you're not using POSIX, you could define EACCESS etc. as glocal
macros yourself, and then this code could break badly...
The implementation could do so, but a program could not; identifiers
starting with a letter E followed either an uppercase letter or a
digit are reserved.
You could test for whatever macro specifies POSIX conformance along
with the test for whether EACCES is defined; that would eliminate the
possibility of a non-POSIX implementation defining EACCES in some
incompatible way.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Erik Trulsson wrote:
jacob navia <ja***@nospam.comwrote:
>I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
Your imagination is obviously not very good.
Take for example CP/M.
This system is a good example of a currently widely
used system isn't it?
The solution for that system is very simple.
filesize reports number of blocks times the size of each block.
Period. Of course this is not the size of the useful bytes but...
who cares? CP/M users know that!
>
Another example would be a file stored on a magnetic tape. There it might not be
possible to find out how large the file is without reading the file until
you reach an end-of-file marker. I am fairly certain that such devices
are still in use.
so what?
filesize searches till the end of the file is found or if the device is
not supported returns an error.
What is obvious is that there are two alternatives:
1) Take the worst possible file system. Then standardize only
what that file system supports.
2) Take the most common situation for current machines and file
systems and standardize what those systems support.
Obviously you support (1). Everybody has to take care of CP/M,
that disappeared more than 20 years ago, System 3090, that disappeared
more or less at the same date...
Yours is the easiest solution: keep C at the PDP-11 / CP/M System 3090
level.
I would propose that those obsolete systems aren't even considered.
If someone implements C in them, then, it is up to the implementation
to see how the standard can be implemented.
For instance, and to go on with CP/M you could store the number
of used bytes in each block at the last 2 bytes of each block
isn't it?
Not very difficult to do.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Eric Sosman wrote:
>
I repeat the question you snipped and have not yet even
begun to answer:
>What is the appropriate action for "file locked," and how
>does it differ from that for "privileges problem?"
For file locked it could be a temporary problem. The program waits
for a certain period and retries.
For a privileges problem you change the file name so that it doesn't
use the name of a file already owned by someone else and retry.
For instance. There are thousands of variations.
> Portable
>actions only, please: you keep talking about portable error
>analysis, which is mere mockery without portable error response.
Wait for a certain time is impossible in standard C. (As I said,
you can't do much in standard C). But that could be a portable
action if the interface level of C wouldn't be so low.
If you like, we can now rephrase it in terms of your list:
For each error code, please explain what "appropriate action"
(your phrase) should be taken, how its action differs from the
actions taken for other codes, and how to take action portably.
You do not understand. The appropriate action depends of the program
OF COURSE. A program may react to ENOENT with changing the mode
from read into write since it was testing if the file exists.
Another it would mean
DialogBox("Configuration file doesn't exist. Create it? (YN)");
Also, do you imagine that the list you exhibit here is an
exhaustive list of failure modes for fopen()?
There is no point in discussing if I address your complaint, and then
you bring it again. I answer it AGAIN and you bring it AGAIN.
I said that there is NO EXHAUSTIVE list. BUt a list with the most
common failures! I have told you this already THREE times.
PLEASE TAKE NOTICE ok?
What code should
an implementation use if fopen() fails for lack of memory?
ENOMEM or the defined portable error code for memory
exhaustion.
What
code reports an incompatibility between the file organization and
C's sequential "stream of bytes" model (c.f. OpenVMS)?
An error code specific to OpenVMS.
What code
is appropriate for a security violation (e.g., low-privilege
program attempting to read a high-privilege file -- note that your
description of EPERM does not cover this case)?
Another, system specific code. AS I TOLD YOU BEFORE
it is NOT exhaustive!
What code should
be used if the file name references an environment variable that
has no definition? What code should be used -- ah, the hell with
it. You have not even begun to think about these problems, much
less solve them.
I said in my message: <fl**********@aioe.org>
<quote>
An implementation would be allowed to extend this errors but we could
portably test for a certain kind of error.
<end quote>
but you just ignore that and go on.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
Erik Trulsson wrote:
>jacob navia <ja***@nospam.comwrote:
>>I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
Your imagination is obviously not very good.
Take for example CP/M.
This system is a good example of a currently widely
used system isn't it?
No, but *that's* a good example of moving the goalposts. You said you
couldn't imagine a file system that doesn't provide a way of knowing the
length of a file, so an example was provided for you. Now you seem to be
rejecting the example. Nevertheless, it is a valid example of a filesystem
that doesn't provide a way of knowing the length of a file. There's no
point in criticising answers that you yourself asked for, provided only
that they are correct. The above answer *is* correct, IIRC - CP/M does
indeed behave like that. Your criterion of "wide use" was not present in
your original question.
The solution for that system is very simple.
filesize reports number of blocks times the size of each block.
Period. Of course this is not the size of the useful bytes but...
who cares?
Not you, it seems. But there are people who have to write code that works
on arbitrary systems. You don't appear to be one of them. So? Just because
you are not such a person, that doesn't mean that such people don't exist.
<snip>
I would propose that those obsolete systems aren't even considered.
Fortunately, those people who are responsible for the Standard are less
ready than you to dismiss systems that are in current use.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:f4******************************@bt.com...
jacob navia said:
>>>I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
....
>>Take for example CP/M.
....
>I would propose that those obsolete systems aren't even considered.
....
Fortunately, those people who are responsible for the Standard are less
ready than you to dismiss systems that are in current use.
Someone creates a new OS with a file system having the innovative idea of
storing the byte-size of each file.
The question is, why would they do that? Because nobody would be allowed to
make use of it; not in Standard C anyway. Or other languages because they
are likely also implemented in C.
How then would a C programmer take advantage of this feature even though
it's only available on a billion or so computers?
Bart
jacob navia wrote:
army1987 wrote:
>jacob navia wrote:
>>fpos_t filesize(FILE *);
would be useful isn't it?
On my system fpos_t isn't an integer. It isn't an arithmetic type, either.
It isn't a scalar, either.
How do I convert an object whose type looks like
typedef struct
{
__off_t __pos;
__mbstate_t __state;
} _G_fpos_t;
typedef _G_fpos_t fpos_t;
to a number?
you convert the __pos member into a long long.
That was not the point. fpos_t can be different things on different
systems, so, to portably convert it to a size, we would need another
function e.g. long fpos_t2bytecount(fpos_t), so why don't have the
function filesize directly return...
In any case I would say that a long long
result would be a better return type.
Indeed.
--
Army1987 (Replace "NOSPAM" with "email")
On Dec 26, 5:46*pm, gordonb.0h...@burditt.org (Gordon Burditt) wrote:
This functionality cannot be achieved. =A0It is literally impossible on
a multi-user system for obvious reasons.
Please stop that. With the same arguments I can tell that
fseek() is bogus since somebody else can erase the
file after you do your fseek.
ftell: same problem.
fread: the same
fwrite: the same. You wrote something but root took it away.
Really? *You have the file open and seek to a position and the OS lets
someone else delete it? *Marvelous. *
Yes, and furthermore you can still read from the file, or write to it,
*AFTER* someone else deletes it (until you fclose() it).
Show me this system that I may
stand in astonishment. *
UNIX or POSIX.
My instance is not deleted until I exit the program. So the accuracy
of the fseek(), ftell() etc. functions is undamaged.
[Windows example of deleting failing on open file deleted.]
Bart C wrote:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:f4******************************@bt.com...
>jacob navia said:
>>>>I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
...
>>>Take for example CP/M.
...
>>I would propose that those obsolete systems aren't even considered.
...
>Fortunately, those people who are responsible for the Standard are less
ready than you to dismiss systems that are in current use.
Someone creates a new OS with a file system having the innovative idea of
storing the byte-size of each file.
The question is, why would they do that? Because nobody would be allowed to
make use of it; not in Standard C anyway. Or other languages because they
are likely also implemented in C.
How then would a C programmer take advantage of this feature even though
it's only available on a billion or so computers?
Bart
Easy. The programmer would use one of the OS specific functions
supplied by the OS. For example, int stat(const char *path, struct stat
*sb). True, his code then becomes non-portable, but then again, he is
asking to do something inherently non-portable!
And most importantly, from a practical point of view, it really doesn't
seem to have stopped anyone from using C to do exactly this.
Stephen
"Eric Sosman" <es*****@ieee-dot-org.invalidwrote in message
news:4f******************************@comcast.com. ..
Bart C wrote:
>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)
Several things are wrong with it, even apart from the
possible 64KB limit.
I'll let that go.
Zeroth, you should have #include'd <stdio.h>. I'll let
you get away with this one, though, on the grounds that since
This is a code fragment. Assume headers are included for all C library
calls.
First, there's no error checking. None, nada, zero, zip.
I wasn't aware there was much to go wrong. But I will have a look. At worst
it will return the wrong file size; I'll make it return all 0's or or 1's or
something.
Second, ftell() returns a long. When you store the long
I'll change the types to long too, since it can't go past 2GB-1 anyway.
Third, what are the magic numbers 2 and 0 that you use
as the third arguments in the fseek() calls? My guess is
that they are the expansions of the macros SEEK_END and
SEEK_CUR on some system you once used, and that you've
decided for some bizarre reason to avoid using the macros.
Close. The code existed in a non-C language, but using the C runtime,
without access to the headers and it was easiest to plug in these constants.
Converted to C (and tested) for the post.
Fourth, for a text stream the value returned by ftell() is
not necessarily a byte count; it is a value with an unspecified
encoding. Calling it a "file size" makes unwarranted assumptions.
My assumption is the file is in binary mode; and my wrapper of the fopen()
function ensures that.
Fifth, there's 7.19.9.2p3: "A binary stream need not...
Sixth, for a binary stream there may be an unspecified...
I don't get these. There are known issues when used with files currently
open for writing. And I know the host OS in *my* case. But yes, anyone
attempting to use this code on their OS should be aware of limitations.
But other than that, it looks pretty good.
Thanks (?)
Bart
On Dec 27, 12:21*pm, jacob navia <ja...@nospam.comwrote:
Erik Trulsson wrote:
jacob navia <ja...@nospam.comwrote:
I just can't imagine a file system that doesn't provide a way
of knowing the length of a file.
Your imagination is obviously not very good.
Take for example CP/M. *
This system is a good example of a currently widely
used system isn't it?
The solution for that system is very simple.
filesize reports number of blocks times the size of each block.
Period. Of course this is not the size of the useful bytes but...
who cares? * CP/M users know that!
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
Next Cmd: dir/size
Directory DKA0:[000000.CONNX75.VMS-BINARIES]
LINK.COM;6 2
VAXCRTL.OPT;6 1
ZIP.AXP_OLB;6 730
ZIP.HLP;6 49
ZIP.I64_OLB;6 871
ZIP.VAX_DECC_OLB;6 218
ZIP.VAX_VAXC_OLB;6 201
ZIPCLI.AXP_OLB;6 292
ZIPCLI.I64_OLB;6 459
ZIPCLI.VAX_DECC_OLB;6
96
ZIPCLI.VAX_VAXC_OLB;6
84
ZIPCLOAK.AXP_OBJ;6 61
ZIPCLOAK.I64_OBJ;6 54
ZIPCLOAK.VAX_DECC_OBJ;6
22
ZIPCLOAK.VAX_VAXC_OBJ;6
22
ZIPNOTE.AXP_OBJ;6 70
ZIPNOTE.I64_OBJ;6 60
ZIPNOTE.VAX_DECC_OBJ;6
26
ZIPNOTE.VAX_VAXC_OBJ;6
26
ZIPSPLIT.AXP_OBJ;6 81
ZIPSPLIT.I64_OBJ;6 83
ZIPSPLIT.VAX_DECC_OBJ;6
31
ZIPSPLIT.VAX_VAXC_OBJ;6
29
ZIPUTILS.AXP_OLB;6 240
ZIPUTILS.I64_OLB;6 432
ZIPUTILS.VAX_DECC_OLB;6
62
ZIPUTILS.VAX_VAXC_OLB;6
59
ZIP_CLI.HLP;6 43
Total of 28 files, 4404 blocks.
Next Cmd:
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want. http://h71000.www7.hp.com/openvms/hw_supportchart.html
>
Another example would be a file stored on a magnetic tape. *There it might not be
possible to find out how large the file is without reading the file until
you reach an end-of-file marker. *I am fairly certain that such devices
are still in use.
so what?
filesize searches till the end of the file is found or if the device is
not supported returns an error.
What is obvious is that there are two alternatives:
1) Take the worst possible file system. Then standardize only
* * what that file system supports.
2) Take the most common situation for current machines and file
* * systems and standardize what those systems support.
Obviously you support (1). Everybody has to take care of CP/M,
that disappeared more than 20 years ago, System 3090, that disappeared
more or less at the same date...
Yours is the easiest solution: keep C at the PDP-11 / CP/M System 3090
level.
I would propose that those obsolete systems aren't even considered.
If someone implements C in them, then, it is up to the implementation
to see how the standard can be implemented.
For instance, and to go on with CP/M you could store the number
of used bytes in each block at the last 2 bytes of each block
isn't it?
Not very difficult to do.
The fact that sizes are not reported in bytes on some systems is not
nearly so large a hurdle as the fact that on live systems file sizes
are constantly changing. You are proposing a function that cannot
possibly work (reporting file size on a live file). It's not an
intelligent API.
On Dec 26, 6:52*pm, Stephen Montgomery-Smith <step...@missouri.edu>
wrote:
user923005 wrote:
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.
Yes, but inflammatory exchanges is a major part of what makes this group
so fun to read. *So please don't discourage his participation!
Inflamatory exchanges do not lead to progress (IMO-YMMV).
If we are unable to act in a civil manner, it is an embarassment (or
should be).
user923005 wrote:
On Dec 26, 6:52 pm, Stephen Montgomery-Smith <step...@missouri.edu>
wrote:
>user923005 wrote:
>>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.
Yes, but inflammatory exchanges is a major part of what makes this group
so fun to read. So please don't discourage his participation!
Inflamatory exchanges do not lead to progress (IMO-YMMV).
If we are unable to act in a civil manner, it is an embarassment (or
should be).
Well, yes, it should certainly be an embarrassment! But it is what it
is, so we may as well enjoy it for what it is.
Bart C wrote:
"Eric Sosman" <es*****@ieee-dot-org.invalidwrote in message
news:4f******************************@comcast.com. ..
Bart C wrote:
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;
}
....
First, there's no error checking. None, nada, zero, zip.
I wasn't aware there was much to go wrong. But I will have a look. At worst
it will return the wrong file size; I'll make it return all 0's or or 1's or
something.
Every single standard library function you called has a possibility of
failing. ftell() returns -1 when it fails; fseek() returns a non-zero
value when it fails. You check for neither possibility. Also, handle
might be an invalid pointer (which you unfortunately can't check in
any portable fashion), or it could be NULL (which you can).
user923005 wrote:
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
[big snip]
>
Total of 28 files, 4404 blocks.
Next Cmd:
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want.
http://h71000.www7.hp.com/openvms/hw_supportchart.html
If you have one of that systems and your trash is full so you can't get
rid of it, then you can do the following http://h71000.www7.hp.com/wizard/wiz_5424.html
Obtaining RMS file size?
Hello Mr Wizard
I am looking for a method of obtaining the size of a file, NOT the
allocation
from within a Fortran routine. I thought this would be a simple
trivial task
but alas I am proved wrong.
Can you help.
Regards Jim
Answer
RMS does NOT keep track of the number of user data bytes in a file.
The only reliable way to obtain that, is to read the file and count!
So there you have the answer!
If you are using that system expect that filesize() will take some time.
So What?
Should we ALL suffer because some brain-dead system exists somewhere?
No.
Only the users of THAT system should be the ones of coping with their
choices not all others!
>
The fact that sizes are not reported in bytes on some systems is not
nearly so large a hurdle as the fact that on live systems file sizes
are constantly changing.
The function returns the size AT THE TIME OF THE CALL. I have repeated
this AGAIN AND AGAIN and I am repeating here AGAIN:
"AT THE TIME OF THE CALL"
If the file size changes later IT IS NOT THE PROBLEM OF THE API!
You are proposing a function that cannot
possibly work (reporting file size on a live file). It's not an
intelligent API.
If you say that because it takes a file pointer the file is "live"
that's another question. Maybe it would better be a file NAME and not a
handle to a file.
What is important is that we can use a portable function in MOST file
systems. I am tired of this levelling through the worst that is going on
here.
This insistence of getting the WORST system then FORCING all other
people to adapt themselves to that pile of sh...!
CP/M, it is DEAD.
OpenVMS? It is dying.
Anyway, I always avoided the VAX, and I am glad I did!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Dec 27, 1:58*pm, Stephen Montgomery-Smith
<step...@math.missouri.eduwrote:
user923005 wrote:
On Dec 26, 6:52 pm, Stephen Montgomery-Smith <step...@missouri.edu>
wrote:
user923005 wrote:
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.
Yes, but inflammatory exchanges is a major part of what makes this group
so fun to read. *So please don't discourage his participation!
Inflamatory exchanges do not lead to progress (IMO-YMMV).
If we are unable to act in a civil manner, it is an embarassment (or
should be).
Well, yes, it should certainly be an embarrassment! *But it is what it
is, so we may as well enjoy it for what it is.
While I will admit that trollish posts are sometimes fun, the correct
model for posting is that of Tanmoy Bhattacharya and Chris Torek.
Which is to say:
Knowledgeable
Non-judgemental
Polite
Correct
Succinct
Informative
Interesting
etc.
Anything less is a defect on the part of the poster. My posts are
often defective. I also admit that when a troller is hanging like
some tempting Pińata, I am often prone to take a swing.
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.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Dec 27, 2:01*pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
[big snip]
Total of 28 files, 4404 blocks.
Next Cmd:
each of those file sizes is 512 byte increments. *You can buy a new
one today from HP, if you want.
http://h71000.www7.hp.com/openvms/hw_supportchart.html
If you have one of that systems and your trash is full so you can't get
rid of it, then you can do the following
http://h71000.www7.hp.com/wizard/wiz_5424.html
Obtaining RMS file size?
Hello Mr Wizard
I am looking for a method of obtaining the size of a file, NOT the
allocation
* from within a Fortran routine. I thought this would be a simple
trivial task
* but alas I am proved wrong.
Can you help.
Regards Jim
Answer
* * *RMS does NOT keep track of the number of user data bytes in a file.
* * *The only reliable way to obtain that, is to read the file and count!
So there you have the answer!
If you are using that system expect that filesize() will take some time.
So What?
Should we ALL suffer because some brain-dead system exists somewhere?
No.
Only the users of THAT system should be the ones of coping with their
choices not all others!
I have already said in previous posts that OpenVMS file size may be
obtained by table scan. This is a very unfriendly operation on a live
system and you had better have a darn good reason for doing it. You
have to lock each record as you read it to get a result that is
accurate even for what you saw at the instant of operations (and -- of
course -- each record may be changed or deleted the moment you move to
the next.
The fact that sizes are not reported in bytes on some systems is not
nearly so large a hurdle as the fact that on live systems file sizes
are constantly changing. *
The function returns the size AT THE TIME OF THE CALL. I have repeated
this AGAIN AND AGAIN and I am repeating here AGAIN:
"AT THE TIME OF THE CALL"
But it can change the instant afterwards, so that information has
literally no value at all.
If the file size changes later IT IS NOT THE PROBLEM OF THE API!
You are proposing a function that cannot
possibly work (reporting file size on a live file). *It's not an
intelligent API.
If you say that because it takes a file pointer the file is "live"
that's another question. Maybe it would better be a file NAME and not a
handle to a file.
What is important is that we can use a portable function in MOST file
systems. I am tired of this levelling through the worst that is going on
* here.
The value of collecting a number that can change in an instant seems
rather strange. I assume you want to use it for something (such as
allocating memory so that you can read that file into memory). If the
number cannot be used for that (or any other) purpose, then what good
is the number?
This insistence of getting the WORST system then FORCING all other
people to adapt themselves to that pile of sh...!
CP/M, it is DEAD.
OpenVMS? It is dying.
We make millions of dollars off of OpenVMS. That includes plenty of
new development. The fact that such systems exist shows that your
arguments were simply wrong.
Anyway, I always avoided the VAX, and I am glad I did!
You are shown to be wrong. Did it make you feel foolish?
user923005 said:
<snip>
You are shown to be wrong. Did it make you feel foolish?
An interesting question. I have been shown to be wrong many times, here in
clc. On occasions, yes, it has made me feel foolish. Nevertheless, being
shown to be wrong is an important part of becoming right. The trick is
twofold: not to mind being shown to be wrong, and being able to learn the
relevant lesson, so that one is not shown to be wrong in the same way
twice.
It is a lesson that some people here have yet to learn.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <fl**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>OpenVMS? It is dying.
You have marketshare figures to support that assertion? http://www.hp.com/hpinfo/newsroom/pr...7/071129a.html
PALO ALTO, Calif., Nov. 29, 2007
HP increased its worldwide server unit shipments by 10 times the
total of all other vendors combined in the third calendar quarter
of 2007, according to figures released today by industry analyst
firm IDC.
I don't see OpenVMS shipment figures broken out there, but
HP's overall growth is impressive.
--
"History is a pile of debris" -- Laurie Anderson
On Dec 27, 2:17*pm, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:
<snip>
You are shown to be wrong. *Did it make you feel foolish?
An interesting question. I have been shown to be wrong many times, here in
clc. On occasions, yes, it has made me feel foolish. Nevertheless, being
shown to be wrong is an important part of becoming right. The trick is
twofold: not to mind being shown to be wrong, and being able to learn the
relevant lesson, so that one is not shown to be wrong in the same way
twice.
It is a lesson that some people here have yet to learn.
I think that the 'feeling foolish' bit is the most important part. If
we do not feel any revulsion at continual bad advice, then I think it
will be hard to grow. I feel foolish quite often, because I am
particularly mistake prone. But my mistakes do motivate me to try to
improve.
"user923005" <dc*****@connx.comwrote in message
news:5d**********************************@p69g2000 hsa.googlegroups.com...
>Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
....
>Total of 28 files, 4404 blocks.
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want. http://h71000.www7.hp.com/openvms/hw_supportchart.html
I've had a look, couldn't find the rx1600. How much is one?
[From other reply]
"jacob navia" <ja***@nospam.comwrote in message
news:fl**********@aioe.org...
[from the link]
RMS does NOT keep track of the number of user data bytes in a file.
The only reliable way to obtain that, is to read the file and count!
This suggests that the OS *knows* the byte-size, otherwise how would it know
when to set EOF? Unless it always reads to the end of the last block. And if
it knows, is there no other way of extracting that information?
Would it be possible to position to the start of the last block, and read
bytes until EOF is set? That might be an alternative to reading the entire
file.
Then we can implement 'getfilesize()' efficiently even for this OS, <subject
to the limitations of using this information in a multiprogramming
environment>.
Bart
CJ wrote:
Keith Thompson wrote:
>Or, if you want both flexibility and
portability, you can do something like this (untested code):
if (... fopen failed ...) {
switch (errno) {
#ifdef EACCES
case EACCES:
/* handle permission error */
break;
#endif
.... snip ...
>
But if you're not using POSIX, you could define EACCESS etc. as
glocal macros yourself, and then this code could break badly...
No you can't, because identifiers beginning with an uppercase E
have restrictions imposed on them. Read the C standard. Such a
definition imposes undefined behaviour.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Gordon Burditt wrote:
>
.... snip ... (Somebody fouled the attributions)
>
>Really? You have the file open and seek to a position and the
OS lets someone else delete it? Marvelous.
Yes, and furthermore you can still read from the file, or write
to it, *AFTER* someone else deletes it (until you fclose() it).
>Show me this system that I may stand in astonishment.
UNIX or POSIX.
I believe the quote should have been attributed to Jacob Navia, who
should now have his heels firmly mired in gooey astonishment.
Maybe he should also be shown sparse files?
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
On Dec 27, 1:26*pm, CBFalconer <cbfalco...@yahoo.comwrote:
Gordon Burditt wrote:
... snip ... (Somebody fouled the attributions)
Really? *You have the file open and seek to a position and the
OS lets someone else delete it? *Marvelous.
Yes, and furthermore you can still read from the file, or write
to it, *AFTER* someone else deletes it (until you fclose() it).
Show me this system that I may stand in astonishment.
UNIX or POSIX.
I believe the quote should have been attributed to Jacob Navia, who
should now have his heels firmly mired in gooey astonishment.
Maybe he should also be shown sparse files?
No, it was me. Actually, I knew better (but phrased my question
badly). The issue I was trying to address is about the standard
library functions such as fseek(), ftell(), etc. which still work
correctly during my session. *My* instance of the file is not deleted
until I exit, but in reality the file has been deleted as far as the
OS is concerned (since it will appear deleted to other users if the
delete operation succeeded).
So the only thing I can really say here is: "I stand corrected."
Perhaps I sould stand in astonishment, but I am not astonished by what
I already knew. Perhaps I am a little astonished at the lack of
precision of my question though.
user923005 wrote:
>The function returns the size AT THE TIME OF THE CALL. I have repeated
this AGAIN AND AGAIN and I am repeating here AGAIN:
"AT THE TIME OF THE CALL"
But it can change the instant afterwards, so that information has
literally no value at all.
OK. Then we should get rid of "DIR", "ls -l" and all other
"stupid" program that give "meaningless results".
OK I give up.
There is no point in discussing with somebody that doesn't want
to go into the arguments of the other side. All multi user
OSes provide a "stat" function. This function gives of
course meaningless results and since at least 25 years progammers
use those "meaningless" results. Go figure, they did not know
"user923005" and the virtues of openvms.
P.S. by the way, in the reference I gave to the openvms wizard
there is a COBOL program to get the exact file size and other
attributes of the file. It wasn't anything very difficult as you say.
You are just talking nonsense.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
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!
Then they have the file size. PERIOD. Nothing is "abandoned".
But we could rely on a PORTABLE function to do that instead of
using zig different functions.
What is funny is that precisely the same people that always
get their mouth full of "PORTABILITY IS ALL IMPORTANT"
now argue that improving C by giving more portable functions
is "impossible".
Go figure
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Wed, 26 Dec 2007 21:54:27 +0100, jacob navia wrote:
You can't do *anything* in just standard C.
Well, apparently some people can't. I however have a fairly large library
of smallish programmes written entirely in standard C that did an
excellent job at what I wrote them for.
On Dec 28, 12:01 am, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
[big snip]
Total of 28 files, 4404 blocks.
Next Cmd:
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want.
http://h71000.www7.hp.com/openvms/hw_supportchart.html
If you have one of that systems and your trash is full so you can't get
rid of it, then you can do the following
http://h71000.www7.hp.com/wizard/wiz_5424.html
Obtaining RMS file size?
Hello Mr Wizard
I am looking for a method of obtaining the size of a file, NOT the
allocation
from within a Fortran routine. I thought this would be a simple
trivial task
but alas I am proved wrong.
Can you help.
Regards Jim
Answer
RMS does NOT keep track of the number of user data bytes in a file.
The only reliable way to obtain that, is to read the file and count!
So there you have the answer!
If you are using that system expect that filesize() will take some time.
So What?
Should we ALL suffer because some brain-dead system exists somewhere?
No.
Since you obviously want to target certain systems and not all
systems, why not use the system specific facilities and standards?
Like POSIX or the UNIX specification?
Walter Roberson wrote:
In article <fl**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>OpenVMS? It is dying.
You have marketshare figures to support that assertion?
http://www.hp.com/hpinfo/newsroom/pr...7/071129a.html
PALO ALTO, Calif., Nov. 29, 2007
HP increased its worldwide server unit shipments by 10 times the
total of all other vendors combined in the third calendar quarter
of 2007, according to figures released today by industry analyst
firm IDC.
I don't see OpenVMS shipment figures broken out there, but
HP's overall growth is impressive.
HP is waiting that the thing dies a natural death. There is
no new development and HP waits till the users get tired and
migrate to other systems http://www.theinquirer.net/en/inquir...me-hp-sold-it-
Nothing new since then (2003)
The system is very old, and probably will take some time till it
disappears.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Wed, 26 Dec 2007 21:31:44 -0600, Stephen Montgomery-Smith wrote:
postings. Now if only the regulars could learn to be more friendly and
patient in redirecting newcomers to the groups they really need
The problem is, after 15+ years of directing traffic, you get /really/
fed up being asked the same offtopic questions over and over. Especially
when there's a FAQ.
Bart C wrote:
"user923005" <dc*****@connx.comwrote in message
news:5d**********************************@p69g2000 hsa.googlegroups.com...
>Here is a machine (HP RX/1600 Itanium running OpenVMS) that reports
its file sizes in blocks.
...
>Total of 28 files, 4404 blocks.
each of those file sizes is 512 byte increments. You can buy a new
one today from HP, if you want.
http://h71000.www7.hp.com/openvms/hw_supportchart.html
I've had a look, couldn't find the rx1600. How much is one?
[From other reply]
"jacob navia" <ja***@nospam.comwrote in message
news:fl**********@aioe.org...
[from the link]
> RMS does NOT keep track of the number of user data bytes in a file.
The only reliable way to obtain that, is to read the file and count!
This suggests that the OS *knows* the byte-size, otherwise how would it know
when to set EOF? Unless it always reads to the end of the last block. And if
it knows, is there no other way of extracting that information?
Would it be possible to position to the start of the last block, and read
bytes until EOF is set? That might be an alternative to reading the entire
file.
Then we can implement 'getfilesize()' efficiently even for this OS, <subject
to the limitations of using this information in a multiprogramming
environment>.
Bart
There is a COBOL program that does it (or maybe not COBOL
but DCL, who knows) in the link I gave
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
user923005 wrote:
Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:
<snip>
>>You are shown to be wrong. Did it make you feel foolish?
An interesting question. I have been shown to be wrong many times,
here in clc. On occasions, yes, it has made me feel foolish.
Nevertheless, being shown to be wrong is an important part of
becoming right. The trick is twofold: not to mind being shown to
be wrong, and being able to learn the relevant lesson, so that one
is not shown to be wrong in the same way twice.
It is a lesson that some people here have yet to learn.
I think that the 'feeling foolish' bit is the most important part.
If we do not feel any revulsion at continual bad advice, then I
think it will be hard to grow. I feel foolish quite often,
because I am particularly mistake prone. But my mistakes do
motivate me to try to improve.
No, I think you have the game rules all mixed up. It is much
better to simply deny the proof of wrongness, with associated
comments such as 'stupid' or 'obsolete'. This also provides the
very useful opportunity to make fun of people with an adequate
understanding of the problem. If you are successful, you can get
those 'understanders' ignored by the unknowing reading your posts.
Careful snipping of all worthwhile responses is a very useful
skill.
Remember that ALL computers act just like Winders. Anything else
is not to be considered.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
In article <fl**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>Walter Roberson wrote:
>In article <fl**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>OpenVMS? It is dying.
>HP is waiting that the thing dies a natural death. There is
no new development and HP waits till the users get tired and
migrate to other systems
>http://www.theinquirer.net/en/inquir...me-hp-sold-it-
>Nothing new since then (2003)
That was written before OpenVMS for Itanium was released. OpenVMS
was indeed released for Itanium, and also for Integrity (e.g.,
BladeSystem c-Class)
Version 8.3-1H1 was released October 25, 2007. http://h71000.www7.hp.com/openvms/op...portchart.html http://en.wikipedia.org/wiki/OpenVMS
--
"Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us." -- Ecclesiastes
On Dec 27, 3:23*pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
The function returns the size AT THE TIME OF THE CALL. I have repeated
this AGAIN AND AGAIN and I am repeating here AGAIN:
"AT THE TIME OF THE CALL"
But it can change the instant afterwards, so that information has
literally no value at all.
OK. Then we should get rid of "DIR", "ls -l" and all other
"stupid" program that give "meaningless results".
Often (if you ask for it) dir and ls or other variants will give you
file size estimates.
OK I give up.
There is no point in discussing with somebody that doesn't want
to go into the arguments of the other side. All multi user
OSes provide a "stat" function.
Not true. Some do, some don't
This function gives of
course meaningless results and since at least 25 years progammers
use those "meaningless" results. Go figure, they did not know
"user923005" and the virtues of openvms.
It is true that you can use things like directory listings for systems
management planning. But it is useless within a C program for
purposes such as allocation of a memory buffer to hold the contents of
the file (which is what started this thread).
P.S. by the way, in the reference I gave to the openvms wizard
there is a COBOL program to get the exact file size and other
attributes of the file. It wasn't anything very difficult as you say.
I already said how to do it before you ever posted the link, way
upthread. The COBOL program will have to do a table scan. This is a
very expensive operation.
You are just talking nonsense.
What are you going to do with your filesize() function?
On Dec 27, 3:26*pm, jacob navia <ja...@nospam.comwrote:
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 needa
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?
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
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.
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.
Go figure
On Thu, 27 Dec 2007 23:51:15 +0000, Walter Roberson wrote:
In article <fl**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Walter Roberson wrote:
>>In article <fl**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>>OpenVMS? It is dying.
>>HP is waiting that the thing dies a natural death. There is no new
development and HP waits till the users get tired and migrate to other
systems
Its going to take a long time, while they continue to sell hobbyist
licenses for only $40 pa, simh continues to exist and Vax Workstations
can be picked up on eBay for less than an intel laptop. I'm currently
running V7.3 on an old intel box and its quite nice actually!
Version 8.3-1H1 was released October 25, 2007.
And now I'm trying to work out how to upgrade....
On Dec 27, 4:02 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
On Thu, 27 Dec 2007 23:51:15 +0000, Walter Roberson wrote:
In article <fl1cs5$1b...@aioe.org>, jacob navia <ja...@nospam.org>
wrote:
>Walter Roberson wrote:
In article <fl17c2$f3...@aioe.org>, jacob navia <ja...@nospam.org>
wrote:
>>OpenVMS? It is dying.
>HP is waiting that the thing dies a natural death. There is no new
development and HP waits till the users get tired and migrate to other
systems
Its going to take a long time, while they continue to sell hobbyist
licenses for only $40 pa, simh continues to exist and Vax Workstations
can be picked up on eBay for less than an intel laptop. I'm currently
running V7.3 on an old intel box and its quite nice actually!
Simh performance is vaxlike, though (ugh!). You can get an nice DS10L from
here for a cheap price: http://www.islandco.com/alpha_systems.html
Version 8.3-1H1 was released October 25, 2007.
And now I'm trying to work out how to upgrade....
--
Posted via a free Usenet account from http://www.teranews.com
Dann Corbit wrote:
On Dec 27, 4:02 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
>On Thu, 27 Dec 2007 23:51:15 +0000, Walter Roberson wrote:
>>In article <fl1cs5$1b...@aioe.org>, jacob navia <ja...@nospam.org>
wrote:
Walter Roberson wrote:
In article <fl17c2$f3...@aioe.org>, jacob navia <ja...@nospam.org>
wrote:
>OpenVMS? It is dying.
HP is waiting that the thing dies a natural death. There is no new
development and HP waits till the users get tired and migrate to other
systems
Its going to take a long time, while they continue to sell hobbyist
licenses for only $40 pa, simh continues to exist and Vax Workstations
can be picked up on eBay for less than an intel laptop. I'm currently
running V7.3 on an old intel box and its quite nice actually!
Simh performance is vaxlike, though (ugh!). You can get an nice DS10L from
here for a cheap price:
http://www.islandco.com/alpha_systems.html
Look at that:
AlphaServer DS10L Noname pc clone (my machine)
466Mhz CPU EV6 2GHZ Dual core AMD
256MB Memory 2GB memory
30GB IDE 7200RPM Disk 1000 GB disk storage
Dual Serial Port 2 USB
Dual 10/100 Ethernet Dual 100 Ethernet
1 Open PCI Slot 3 PCI slot
Power Cord Power cord, keyboard, mouse
1 Year Island Warranty 1 year warranty
$699 600 Euros
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Dec 27, 4:10 pm, Richard Heathfield <r...@see.sig.invalidwrote:
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.
One could say that C shouldn't provide any file operations at
all, and let vendors provide extensions for that, since it may
not make sense to "open a file" on some systems. What exactly
is the difference between fopen() and fgetfilesizeforJN()
(except the obvious one, that one is standard, and the other
one is imaginary)? Sure thing, getting a thing like stat() into
the standard would be an incredibly hard task, but it's not the
kind of things you are talking about, is it?
Yevgen
<ym******@gmail.comwrote in message
news:9d**********************************@s8g2000p rg.googlegroups.com...
On Dec 27, 4:10 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>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.
One could say that C shouldn't provide any file operations at
all, and let vendors provide extensions for that, since it may
not make sense to "open a file" on some systems. What exactly
is the difference between fopen() and fgetfilesizeforJN()
(except the obvious one, that one is standard, and the other
one is imaginary)? Sure thing, getting a thing like stat() into
the standard would be an incredibly hard task, but it's not the
kind of things you are talking about, is it?
Opening a file is (in a sense) inherently non-portable.
Indeed, in the case of a toaster IC, there may be no such concept available.
However, on systems like that, the non-hosted rules apply.
Every C program pretty well needs to be able to open a file if it wants to
work with anything other than the three already opened files (stdin, stdout,
stderr). The functionality of fopen() must therefore be present to get just
about anything useful done.
Quite likely, system specific file operations will also be available under
OS specific APIs (e.g. sys$open() in lieu of fopen() on OpenVMS or
CreateFile() in Win32).
These functions will (no doubt) be supplied by the compiler vendor.
--
Posted via a free Usenet account from http://www.teranews.com
You can't do *anything* in just standard C.
This is quite true in case of embedded systems. The standard does not seem
to have the notion of
object files, sections, addressing modes and linking. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Matt |
last post by:
I always heard dialet of programming language. Or implementation of a
programming language. What does it really mean? C++ is standardized
already, does it mean it doesn't have any dialets? But I...
|
by: user |
last post by:
Hi all,
At the outset, I regret having to post this slightly OT post here.
However, I strongly feel that people in this group would be the best to
advise me on my predicament.
I am working as...
|
by: Jesse B. |
last post by:
I've been learning how to program with C, and I can't find any info about
GUI programming with C. I'm almost done with O'reilly's Practical
programming with C, and would like to mess around with...
|
by: evolnet.regular |
last post by:
I've been utilising C for lots of small and a few medium-sized personal
projects over the course of the past decade, and I've realised lately
just how little progress it's made since then. I've...
|
by: Sreekanth |
last post by:
Hi all,
I have implemented a timing out version of fgets function call. I am
pasting the entire code below. I have following doubts:
1. The code which I have written does it follow standard C...
|
by: Robert Seacord |
last post by:
The CERT/CC has just deployed a new web site dedicated to developing
secure coding standards for the C programming language, C++, and
eventually other programming language.
We have already...
|
by: Joe Mayo |
last post by:
I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only...
|
by: istillshine |
last post by:
There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?
I like C...
|
by: =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= |
last post by:
As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
