How to get file size?

[Mark McIntyre]

And I've never seen a planet whose gravity was other than one gee, or
a Native Australian. That clearly means /they/ don't exist either.

I've never seen copx or jacob navia in real life. Obviously, they only
exist on Usenet. Then again, I've never met Mark McIntyre, either...[/QUOTE]

Actually you have. I'm right behind you now, in my black helicopter.

 

[Default User]

In american english. Smith is the most common name in english

english.


It's not true in the USA either. Smith is the most common surname here
as well.




Brian

 

[Michael Wojcik]

It's not true in the USA either. Smith is the most common surname here
as well.

At least it was in 1990, the most recent year for which the US Census
Bureau has compiled figures. Slightly more than 1% of all people in
the US have the surname Smith. Johnson is #2, with about 0.8%.

For masculine given names, James outranks John, but only marginally.

Unfortunately, the data doesn't appear to include frequencies of
given / surname pairs.

http://www.census.gov/genealogy/names/names_files.html

 

[Jack Klein]

Dear copx
I proposed several months ago the same solution as you and
received the same pompous answers as you have received.

I have never seen any system where that would fail, sorry.
And the guys throwing nonsense didn't ever show me an example
where this would fail:

1:
Open file under binary mode
2:
Go to end

3:
measure position

4:
close

5:
return position as file length.

I have never seen a system where setting the file pointer at
the end would fail.

Apparently you never used C (pre ANSI, but nevertheless C) under CP/M
80? The only information available from the operating system, and
therefore all you could get without reading and counting, was the
number of 128 octet blocks that the file occupied. Even the operating
system did not know the exact size of any file more accurately than
that.

That is in fact the reason that MS-DOS adopted the CP/M convention of
terminating text files with a special character, 0x1a, after the last
valid character.

But maybe, as you proposed, in DeathSystem 9000 it doesn't work...

Don't even get me started about some of the file systems out there...

 

[Jack Klein]

I quote from the C standard:
A binary stream is an ordered sequence of characters that can
transparently record
internal data. Data read in from a binary stream shall compare equal to
the data that were
earlier written out to that stream, under the same implementation.

So far, so good. So now where in the C standard does it state that
this number of characters is exactly equal to a number that you can
obtain from a system call? Where in fact does the C standard state
anything about where or how the data is stored?

 

[Keith Thompson]

On Wed, 27 Apr 2005 14:19:16 +0200, jacob navia


Apparently you never used C (pre ANSI, but nevertheless C) under CP/M
80? The only information available from the operating system, and
therefore all you could get without reading and counting, was the
number of 128 octet blocks that the file occupied. Even the operating
system did not know the exact size of any file more accurately than
that.

That is in fact the reason that MS-DOS adopted the CP/M convention of
terminating text files with a special character, 0x1a, after the last
valid character.

Many years ago, I used a system in which every file was a whole number
of 512-byte blocks (1 byte = 8 bits). I think there was a field in
the directory entry that specified the number of bytes in the last
block (allowing you to determine the total size in bytes), but it was
seldom used. A text file consisted of a whole number of 2-block
pages. The first page was typically all zeros (but could be used by
the text editor to store additional information.) Each page after
that consisted of one or more lines. Lines couldn't cross page
boundaries; each page was padded with zeros. Each line consisted of
ASCII characters terminated by a CR, but multiple leading spaces could
optionally be encoded as a DLE character followed a byte equal to the
number of spaces plus 32 (an optimization for indented source code).

On this system, what is the "size" of a text file? (That's a
rhetorical question; there's no one definitive answer.)

(I don't know of a C implementation for this system, but there's no
reason one couldn't have been written.)

 

[CBFalconer]

.... snip ...

Many years ago, I used a system in which every file was a whole number
of 512-byte blocks (1 byte = 8 bits). I think there was a field in
the directory entry that specified the number of bytes in the last
block (allowing you to determine the total size in bytes), but it was
seldom used. A text file consisted of a whole number of 2-block
pages. The first page was typically all zeros (but could be used by
the text editor to store additional information.) Each page after
that consisted of one or more lines. Lines couldn't cross page
boundaries; each page was padded with zeros. Each line consisted of
ASCII characters terminated by a CR, but multiple leading spaces could
optionally be encoded as a DLE character followed a byte equal to the
number of spaces plus 32 (an optimization for indented source code).

On this system, what is the "size" of a text file? (That's a
rhetorical question; there's no one definitive answer.)

Every single one of those features have shown up under cp/m. CP/M
3 had (and dosplus 2.5) had the exact size field (for 128 byte
records). Various software created and used the DLE n indentation
coding. Many systems used an initial record for file
characteristics, although it wasn't necessarily built into the OS
(It was on the HP3000 under MPE).

A fairly unusual system was the SUBmit (or JOB) working script
file, which was written backward in 128 byte fixed length text
lines.

 

[Joe Wright]

Apparently you never used C (pre ANSI, but nevertheless C) under CP/M
80? The only information available from the operating system, and
therefore all you could get without reading and counting, was the
number of 128 octet blocks that the file occupied. Even the operating
system did not know the exact size of any file more accurately than
that.

That is in fact the reason that MS-DOS adopted the CP/M convention of
terminating text files with a special character, 0x1a, after the last
valid character.




Don't even get me started about some of the file systems out there...

I don't have CP/M running anymore (CBFalconer?) but used to with a C
compiler from Software Toolworks. fseek(fp, 0, 2) had no problem finding
that 0x1a character and subsequent ftell(fp) would correctly return its
offset within the file.

 

[CBFalconer]

.... snip ...

I don't have CP/M running anymore (CBFalconer?) but used to with a
C compiler from Software Toolworks. fseek(fp, 0, 2) had no problem
finding that 0x1a character and subsequent ftell(fp) would
correctly return its offset within the file.

Nor do I, except with a simulator around here somewhere But I
do remember a bit about it, and my replacement (dosplus 2.5) is
available.

 

[Stephen Sprunk]

As a fellow sysadmin who also does software development
(some scientific, some tools for administration purposes), I would
ask where you find the *time* to make meaningful programs that are
completely portable and bug free?

Writing mostly-portable code is generally faster than writing
implementation-specific code twice. For those cases where it is not
more efficient (or not possible), you modularize it as much as possible
and make sure the implementation-specific parts are not compiled/linked
on any system they have not been verified on.

Do you take the next 2 or 3 decades to invent a new form of
logical or mathematical analysis to solve the "corner case" just
so you "_know_" the program will work? Or do you document
the condition, put in a smooth failure mode for it, and let it go?

Writing implementation-specific code is fine, though OT for comp.lang.c.
Just make sure you _know_ it's such, document it, and make a reasonable
effort to ensure people won't use it on the wrong platform. In many
environments, just commenting "requires Win32" or "requires POSIX" is
sufficient.

The issue in this thread is that someone responded with code that
happens to work on an implementation or two without any disclaimers as
to it being unportable, then defended it with the completely irrelevant
argument that one vendor of extremely unportable software happens to use
it.

If you're going to post here, make your code portable or suggest another
newsgroup where an unportable solution can be adequately peer-reviewed.
"It works on my system" is not good enough.

S