How to get file size?

"Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
news:d4lijb$16n$1@reader01.news.esat.net...[color=blue]
> Hi all,
> Is there a function in the standard library that can get the size of a
> file?[/color]

Not really but you can easily make one using ftell/fseek.
This should work:

/*
* returns the length of a file (in bytes)
*/
int file_length(FILE *f)
{
int pos;
int end;

pos = ftell (f);
fseek (f, 0, SEEK_END);
end = ftell (f);
fseek (f, pos, SEEK_SET);

return end;
}


HTH,
copx

"copx" <invalid@invalid.com> wrote:
[color=blue]
> "Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
> news:d4lijb$16n$1@reader01.news.esat.net...[color=green]
> > Is there a function in the standard library that can get the size of a
> > file?[/color]
>
> Not really but you can easily make one using ftell/fseek.[/color]

No, you cannot. _Read_ the newsgroup: this has already come up earlier
today, in <mk8m61duov4eiue1tglis9u03k4uqt0jce@4ax.com>.
[color=blue]
> This should work:[/color]

No, it shouldn't. ftell() is meaningful only for binary streams, fseek()
to SEEK_END only for text streams.

Richard

"Sam" <manseesaw@hotmail.com> wrote:
[color=blue]
> Is there a function in the standard library that can get the size of a file?[/color]

No, unfortunately not.

Richard

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:426e51ac.30300072@news.xs4all.nl...[color=blue]
> "copx" <invalid@invalid.com> wrote:
>[color=green]
>> "Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
>> news:d4lijb$16n$1@reader01.news.esat.net...[color=darkred]
>> > Is there a function in the standard library that can get the size of a
>> > file?[/color]
>>
>> Not really but you can easily make one using ftell/fseek.[/color]
>
> No, you cannot. _Read_ the newsgroup: this has already come up earlier
> today, in <mk8m61duov4eiue1tglis9u03k4uqt0jce@4ax.com>.
>[color=green]
>> This should work:[/color]
>
> No, it shouldn't. ftell() is meaningful only for binary streams, fseek()
> to SEEK_END only for text streams.[/color]

But it does. The code is actually an almost straight copy form the Quake 2
source. It does work, on Linux and Windows. Using GCC or multiple Windows
compilers. I mean if it's good enough for ID software it's probably good
enough for everybody.
IMO you're way too academic (i.e. out of touch with programming reality)
here. Where does this NOT work? On the Deathstation 9000?

copx

"Sam" <manseesaw@hotmail.com> writes:
[color=blue]
> Is there a function in the standard library that can get the size of a file?[/color]

No, not reliably.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

"copx" <invalid@invalid.com> wrote:
[color=blue]
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
> news:426e51ac.30300072@news.xs4all.nl...[color=green]
> > "copx" <invalid@invalid.com> wrote:
> >[color=darkred]
> >> "Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
> >> news:d4lijb$16n$1@reader01.news.esat.net...
> >> > Is there a function in the standard library that can get the size of a
> >> > file?
> >>
> >> Not really but you can easily make one using ftell/fseek.[/color]
> >
> > No, you cannot. _Read_ the newsgroup: this has already come up earlier
> > today, in <mk8m61duov4eiue1tglis9u03k4uqt0jce@4ax.com>.
> >[color=darkred]
> >> This should work:[/color]
> >
> > No, it shouldn't. ftell() is meaningful only for binary streams, fseek()
> > to SEEK_END only for text streams.[/color]
>
> But it does.[/color]

Chapter and verse, please.
[color=blue]
> The code is actually an almost straight copy form the Quake 2
> source.[/color]

So bloody what? I could copy code from my programs that involves
WinMain(), initgraph() and setmode(), but that doesn't mean that any of
those are correct ISO C, or on topic in this newsgroup.
[color=blue]
> I mean if it's good enough for ID software it's probably good
> enough for everybody.[/color]

I hope never to encounter a program written by you. They don't work,
they "work" "good enough". As a sysadmin, I want programs that I _know_
work, not that someone has guessed probably would work everywhere he
could think of.

Richard

copx wrote:[color=blue]
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
> news:426e51ac.30300072@news.xs4all.nl...
>[color=green]
>>"copx" <invalid@invalid.com> wrote:
>>
>>[color=darkred]
>>>"Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
>>>news:d4lijb$16n$1@reader01.news.esat.net...
>>>
>>>>Is there a function in the standard library that can get the size of a
>>>>file?
>>>
>>>Not really but you can easily make one using ftell/fseek.[/color]
>>
>>No, you cannot. _Read_ the newsgroup: this has already come up earlier
>>today, in <mk8m61duov4eiue1tglis9u03k4uqt0jce@4ax.com>.
>>
>>[color=darkred]
>>>This should work:[/color]
>>
>>No, it shouldn't. ftell() is meaningful only for binary streams, fseek()
>>to SEEK_END only for text streams.[/color]
>
>
> But it does. The code is actually an almost straight copy form the Quake 2
> source. It does work, on Linux and Windows.[/color]

Would you care to place a small wager? Despite your
assertion, it does not "work" on Windows. Try it on any
non-empty Windows text file of your choosing, and compare
the result to what you get by reading and counting the
characters one by one.
[color=blue]
> Using GCC or multiple Windows
> compilers. I mean if it's good enough for ID software it's probably good
> enough for everybody.[/color]

Yurrgh ...
[color=blue]
> IMO you're way too academic (i.e. out of touch with programming reality)
> here. Where does this NOT work? On the Deathstation 9000?[/color]

Doesn't work on Windows, as mentioned above. Doesn't
work on "native" text files on OpenVMS. Doesn't work on
any text file that represents end-of-line by anything other
than precisely one byte.[*]
[*] Assuming an fseek() implementation that uses "random
access." It would be possible to implement fseek() in terms
of rewind() and a character-counting loop, with assistance
from the implementations of some other <stdio.h> functions,
but an fseek() that can "jump to the end" will be unable to
count the number of line terminators in the skipped portion.

IMO you're way too eager to generalize limited experience
into Universal Truth -- especially since your own experience,
had you bothered to examine it, would have contradicted your
generalization. You're not out of touch with programming
reality, you're *in* touch with programming fiction.

--
Join Bytes!

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:426e5e07.33463785@news.xs4all.nl...[color=blue]
> "copx" <invalid@invalid.com> wrote:
>[color=green]
>> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
>> news:426e51ac.30300072@news.xs4all.nl...[color=darkred]
>> > "copx" <invalid@invalid.com> wrote:
>> >
>> >> "Sam" <manseesaw@hotmail.com> schrieb im Newsbeitrag
>> >> news:d4lijb$16n$1@reader01.news.esat.net...
>> >> > Is there a function in the standard library that can get the size of
>> >> > a
>> >> > file?
>> >>
>> >> Not really but you can easily make one using ftell/fseek.
>> >
>> > No, you cannot. _Read_ the newsgroup: this has already come up earlier
>> > today, in <mk8m61duov4eiue1tglis9u03k4uqt0jce@4ax.com>.
>> >
>> >> This should work:
>> >
>> > No, it shouldn't. ftell() is meaningful only for binary streams,
>> > fseek()
>> > to SEEK_END only for text streams.[/color]
>>
>> But it does.[/color]
>
> Chapter and verse, please.[/color]

This reminds of a theological discussion...
[color=blue][color=green]
>> The code is actually an almost straight copy form the Quake 2
>> source.[/color]
>
> So bloody what? I could copy code from my programs that involves
> WinMain(), initgraph() and setmode(), but that doesn't mean that any of
> those are correct ISO C, or on topic in this newsgroup.[/color]

I didn't claim that the standard guarantees that it works. However the OP
may doesn't care because he wants to solve a practical programming problem
not worship sacred texts.
[color=blue][color=green]
>> I mean if it's good enough for ID software it's probably good
>> enough for everybody.[/color]
>
> I hope never to encounter a program written by you. They don't work,
> they "work" "good enough". As a sysadmin, I want programs that I _know_
> work, not that someone has guessed probably would work everywhere he
> could think of.[/color]

Just because the ISO C standard says something should work in a specific way
doesn't mean that it actually works this way in REALITY.
And as a sysadim you rely on a lot of non-standardized functionality that
just works because it works and not because some ancient scripture demands
that it works.

BTW in general I try to stick to ISO C and write portable code but at a
certain point portability concerns become ridiculous...

copx

"copx" <invalid@invalid.com> wrote:
[color=blue]
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
> news:426e5e07.33463785@news.xs4all.nl...[color=green]
> > I hope never to encounter a program written by you. They don't work,
> > they "work" "good enough". As a sysadmin, I want programs that I _know_
> > work, not that someone has guessed probably would work everywhere he
> > could think of.[/color]
>
> Just because the ISO C standard says something should work in a specific way
> doesn't mean that it actually works this way in REALITY.
> And as a sysadim you rely on a lot of non-standardized functionality that
> just works because it works and not because some ancient scripture demands
> that it works.
>
> BTW in general I try to stick to ISO C and write portable code but at a
> certain point portability concerns become ridiculous...[/color]

I stand by my comments. If you need system-specific functionality, write
_correct_ system-specific code (and post it elsewhere). If you want to
resort to unreliable hacks, get the fuck off my system. There is a
correct, but system-specific, solution to the file size problem, for the
systems you claim (probably erroneously) your hack works on. Being
system-specific, it is off-topic in comp.lang.c.

Richard

"Eric Sosman" <eric.sosman@sun.com> schrieb im Newsbeitrag
news:d4lnf2$h64$1@news1brm.Central.Sun.COM...
[snip][color=blue][color=green]
>> But it does. The code is actually an almost straight copy form the Quake
>> 2
>> source. It does work, on Linux and Windows.[/color]
>
> Would you care to place a small wager? Despite your
> assertion, it does not "work" on Windows. Try it on any
> non-empty Windows text file of your choosing, and compare
> the result to what you get by reading and counting the
> characters one by one.[/color]
[snip]

If you say it it's probably true I didn't thought of "text files" they are a
platform-specific thing anyway ;)
It works in binary mode on all relevant desktop platforms and that might be
more than enough for the OP.

copx

In article <426e5e07.33463785@news.xs4all.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=blue]
>I hope never to encounter a program written by you. They don't work,
>they "work" "good enough". As a sysadmin, I want programs that I _know_
>work, not that someone has guessed probably would work everywhere he
>could think of.[/color]

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?

Suppose, for example, that you are in the middle of 50,000 lines
of code, and you've done all the error bounds analysis and
you've sorted your values before totalling them and so on, and
you've put in cases for near singularities... and then you realize
that there is -no- known answer for how to handle some of the
extrema. What then? 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?


What do you do when you need an SNMP probe, or need a modem or
'expect' chat script, or need your program to send an email alert?
SNMP and SMTP and sockets and pty and device control are all beyond
the scope of Standard C. Do you refuse to write the tool, on the
grounds that someone might want to -try- to run it on (say) a
cell phone with no Internet link?


I don't know what things are like where you are, but hereabouts,
sysadmin work is full of compromises. The goal around here isn't
to be perfect, but rather to do the best balancing of priorities and
budgets and available time that one can do. The boss doesn't want
the numbers 3 months from now, the boss wants the numbers this afternoon,
because the grant proposal has to be in by 9:00 AM the next morning.
The network management tool doesn't have to support every known model
of network device: the network is ill -now-. The network is under
attack -now-, so don't worry that in theory a firewall interface
name might include an internal colon as well as the usual terminal
colon: do what you need to do NOW. You can clean up later if you ever
manage to "get all the fires put out."
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

copx <invalid@invalid.com> wrote:
[color=blue]
> I didn't claim that the standard guarantees that it works. However the OP
> may doesn't care because he wants to solve a practical programming problem
> not worship sacred texts.[/color]

The OP may also appreciate knowing that your proposed solution is dubious
at best.
[color=blue]
> Just because the ISO C standard says something should work in a specific way
> doesn't mean that it actually works this way in REALITY.[/color]

If something doesn't work the way the ANSI standard says it should,
the implementation in question is not a C implementation. End of story.
[color=blue]
> And as a sysadim you rely on a lot of non-standardized functionality that
> just works because it works and not because some ancient scripture demands
> that it works.[/color]

I hardly think the ANSI standard qualifies as "ancient scripture".

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Join Bytes! (Walter Roberson) wrote:
[color=blue]
> In article <426e5e07.33463785@news.xs4all.nl>,
> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=green]
> >I hope never to encounter a program written by you. They don't work,
> >they "work" "good enough". As a sysadmin, I want programs that I _know_
> >work, not that someone has guessed probably would work everywhere he
> >could think of.[/color]
>
> 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?[/color]

I wrote that I want such programs, not that I always get what I want
:-/. AAMOF, since most of our desktop machines are MS-Windows (for
reasons of *hack* *spit* market compatibility), I know that I never do
completely get what I want. Nevertheless, when I encounter a program
that I _know_ contains such ill-advised code as that under discussion, I
will endeavour not to employ it (and probably get overruled by my B's
PHB's and their *expectorate* market forces, but at least I'll have done
my duty).
[color=blue]
> What do you do when you need an SNMP probe, or need a modem or
> 'expect' chat script, or need your program to send an email alert?
> SNMP and SMTP and sockets and pty and device control are all beyond
> the scope of Standard C.[/color]

Don't be daft. As I already wrote upthread, there are right ways and
wrong ways to write programs which are inherently system-dependent. And
this was a wrong way.

Richard

>[color=blue]
> I stand by my comments.[/color]

But then again, you're a pompous asshole.

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.

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

I think the best thing to do is to ignore this guys.

jacob navia <jacob@jacob.remcomp.fr> wrote:
[color=blue]
> I think the best thing to do is to ignore this guys.[/color]

Ignoring Mr. Sosman and Mr. Bos would be colossally stupid.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica wrote:
[color=blue]
> jacob navia <jacob@jacob.remcomp.fr> wrote:
>[color=green]
>>I think the best thing to do is to ignore this guys.[/color]
>
> Ignoring Mr. Sosman and Mr. Bos would be colossally stupid.[/color]

Ignoring Mr. Sosman is sometimes a good idea, but not in
this case. (Or so it seems to me ...)

In the case at hand, my experience is at variance with
that reported by Mr. Navia, who argues that opening a
binary stream, seeking to the end, and reporting the ftell()
value as the file size is reliable. "I have never seen a
system where setting the file pointer at the end would fail,"
he writes. Well, neither have I ...

... but I *have* seen systems where the result of this
query is (or can be) useless. It tells you how many bytes
you could read from the file with a binary stream, but that
number is only one of several notions of "file size," and
possibly not the notion that the programmer cares about.

The usual reason for wanting to know "the" size of a file
in a C program is to decide how much memory to allocate to
hold the file's content. If the file is in fact a big bag of
binary bytes, Navia's computation will work on every system
I've seen (even though the Standard specifically disavows it,
which suggests that I haven't seen all systems). If the file
is textual, though, and will eventually be read with a text
stream, Navia's result may be well off the mark. Two cases
from real life:

- Navia can overestimate the character count by failing
to account for the translation of multi-byte line-
delimiting sequences to single newline characters.
The commonest example may be Windows' conversion
between \r\n and \n, but others exist -- I've used
one system where the line delimiter can be as long
as *five* bytes.

- Navia can *under*estimate the character count by
being blind to special formatting codes in the file.
This can happen on OpenVMS, where one of the file
formats puts a control prefix on each line indicating
the desired vertical spacing: leave so-and-so many
blank lines before/after this one. When translated
by a text stream, such a prefix can synthesize a
potentially large number of \n characters not actually
present on the disk.

Mr. Navia is a knowledgeable user of C, but in this matter
(as in others) he demonstrates that portability is not among
his principal concerns.

(Pompous enough for ya, Jacob?)

--
Eric Sosman
Join Bytes!lid

Eric Sosman wrote:[color=blue]
> Christopher Benson-Manica wrote:
>[color=green]
>> jacob navia <jacob@jacob.remcomp.fr> wrote:
>>[color=darkred]
>>> I think the best thing to do is to ignore this guys.[/color]
>>
>>
>> Ignoring Mr. Sosman and Mr. Bos would be colossally stupid.[/color]
>
>
> Ignoring Mr. Sosman is sometimes a good idea, but not in
> this case. (Or so it seems to me ...)
>
> In the case at hand, my experience is at variance with
> that reported by Mr. Navia, who argues that opening a
> binary stream, seeking to the end, and reporting the ftell()
> value as the file size is reliable. "I have never seen a
> system where setting the file pointer at the end would fail,"
> he writes. Well, neither have I ...
>[/color]

OK Eric at least we agree with that.
[color=blue]
> ... but I *have* seen systems where the result of this
> query is (or can be) useless. It tells you how many bytes
> you could read from the file with a binary stream, but that
> number is only one of several notions of "file size," and
> possibly not the notion that the programmer cares about.
>[/color]

File size is the number of bytes you get when reading the stuff
in binary mode. As far as I understand this complicated subject,
when you make "DIR" or "ls -l" or whatever your system command
is, the size reported is the actual number of bytes in the "file"
entity. This is (or should be) the same as reported by the above
method.
[color=blue]
> The usual reason for wanting to know "the" size of a file
> in a C program is to decide how much memory to allocate to
> hold the file's content. If the file is in fact a big bag of
> binary bytes, Navia's computation will work on every system
> I've seen (even though the Standard specifically disavows it,
> which suggests that I haven't seen all systems). If the file
> is textual, though, and will eventually be read with a text
> stream, Navia's result may be well off the mark. Two cases
> from real life:
>
> - Navia can overestimate the character count by failing
> to account for the translation of multi-byte line-
> delimiting sequences to single newline characters.
> The commonest example may be Windows' conversion
> between \r\n and \n, but others exist -- I've used
> one system where the line delimiter can be as long
> as *five* bytes.
>[/color]

This is outside the specs. If you read it in text mode this
can be off the mark. A little bit oversize is a very mild bug though.
[color=blue]
> - Navia can *under*estimate the character count by
> being blind to special formatting codes in the file.
> This can happen on OpenVMS, where one of the file
> formats puts a control prefix on each line indicating
> the desired vertical spacing: leave so-and-so many
> blank lines before/after this one. When translated
> by a text stream, such a prefix can synthesize a
> potentially large number of \n characters not actually
> present on the disk.
>[/color]

Ahhh no wonder Digital went under... what a system!

If your "text" mode includes translating tabs into blanks for instance,
that WILL go wrong. But again, we are speaking about BINARY mode
Eric. JUST BINARY MODE ok?

[color=blue]
> Mr. Navia is a knowledgeable user of C, but in this matter
> (as in others) he demonstrates that portability is not among
> his principal concerns.
>
> (Pompous enough for ya, Jacob?)[/color]

Well, yeah can go :-)

> 1: Open file under binary mode[color=blue]
> 2: Go to end
> 3: measure position
> 4: close
> 5: return position as file length.[/color]

I am not too much concerned about portability here but beware of race
conditions (especially with other processes). If you open a file and close
it, you never know what you will get when you reopen it. You may face a
security problem.
--
JS

jacob navia wrote:[color=blue]
> [...]
> If your "text" mode includes translating tabs into blanks for instance,
> that WILL go wrong. But again, we are speaking about BINARY mode
> Eric. JUST BINARY MODE ok?[/color]

The complete text of the question that started this
thread is
[color=blue]
> Hi all,
> Is there a function in the standard library that can get the size of a
> file?
> Thank you very much.
> Sam.[/color]

Please point out where Sam specifies BINARY or JUST
BINARY MODE.

--
Join Bytes!

In article <426f9cdd$0$11724$8fcfb975@news.wanadoo.fr>,
jacob navia <jacob@jacob.remcomp.fr> wrote:[color=blue]
>File size is the number of bytes you get when reading the stuff
>in binary mode.[/color]

Is it? What about files on filesystems such as SGI's XFS, which
permit "holes" in filesystems? Those holes take up no disk space
(beyond the descriptor of the size of the holes). It is not unreasonable
to say that the "file size" of such a file would be the amount of
disk space it occupies, rather than the number of bytes you can read
from it.
[color=blue]
>As far as I understand this complicated subject,
>when you make "DIR" or "ls -l" or whatever your system command
>is, the size reported is the actual number of bytes in the "file"
>entity. This is (or should be) the same as reported by the above
>method.[/color]

I can't help but feel that your experience has been relatively narrow.

There are several operating systems which can transparently compress
and decompress files. The disk space reported may be the compressed
file size, or it may be the uncompressed file size -- it varies with
the OS and the way of asking the question.
[color=blue][color=green]
>> This can happen on OpenVMS, where one of the file
>> formats puts a control prefix on each line indicating
>> the desired vertical spacing: leave so-and-so many
>> blank lines before/after this one.[/color][/color]
[color=blue]
>Ahhh no wonder Digital went under... what a system![/color]
[color=blue]
>If your "text" mode includes translating tabs into blanks for instance,
>that WILL go wrong. But again, we are speaking about BINARY mode
>Eric. JUST BINARY MODE ok?[/color]

VMS has a number of different filesystem formats, each aimed at a
different purpose, and with noticable internal filesystem optimizations
to suit those different purposes. What you get when you read such files
in binary mode is not generally the byte-stream stored on disk. For
example, if you are reading a variable-length record file, when you
read in binary mode you get the -contents- of the record, not the
infrastructure bytes that describe the record. This is not a
"contradiction" in the meaning of "binary" mode, because the other
standard mode, "text mode" would imply that you are reading text
whereas the variable-length record might be (say) a struct written as a
complete object. Binary mode is not necessarily the same as what might
be termed "raw mode".

Another example: executables in VMS may include one or more "patch"
sections, which are additional records intended to overlay a stored
code section -- rather than change the original binary itself
in a non-reversable way, the various patches could be added or
removed as virtual addendums. Considering that executable code
is certainly not what most people would consider as "text", then
when one reads the executable in "binary" mode, one expects to
read out the code stream with all the active modifications made to it.
If one needed to get at the underlying structure (e.g., to add another
patch) then there were RMS (Record Management Services) calls that
could be made for that purpose. Now, what is the "size" of such
an executable? The size of the patched stream, or the amount of disk
space it takes to represent all the records and headers including
patches?
--
Are we *there* yet??

On Wed, 27 Apr 2005 14:19:16 +0200, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:
[color=blue]
>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.[/color]

Then your experience is /even more/ limited than I thought.
[color=blue]
>And the guys throwing nonsense didn't ever show me an example
>where this would fail:[/color]

Seriously, if you can't see the problem, there's no hope for you. But
if you want an example, try this on VMS. I suspect it also fails on
most IBM OSen too, but I'm without an S/360 to try it on... :-)
[color=blue]
>I have never seen a system where setting the file pointer at
>the end would fail.[/color]

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.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Wed, 27 Apr 2005 16:08:31 +0200, in comp.lang.c , jacob navia
<jacob@jacob.remcomp.fr> wrote:
[color=blue]
>File size is the number of bytes you get when reading the stuff
>in binary mode.[/color]

Interesting, if bollocks, definition.

Under VMS, you could write 112 bytes to a file. However its 'filesize'
could, according to this method, be 512 bytes because all VMS file
allocations are in blocks of 512. This is also what DIR shows you, one
block allocated to the file.

Reading all 512 bytes back would give you 400 bytes which didn't
belong to your file. If this happened to be some sort of data file,
you'd end up processing 400 bytes of garbage. Thats why the OS has
system specific functions to determine the amount of actual data. You
should use them, and avoid daft hacks.



--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On 27 Apr 2005 16:06:57 GMT, in comp.lang.c ,
Join Bytes! (Walter Roberson) wrote:
[color=blue]
>Another example: executables in VMS may include one or more "patch"
>sections, which are additional records intended to overlay a stored
>code section -- rather than change the original binary itself
>in a non-reversable way, the various patches could be added or
>removed as virtual addendums. Considering that executable code
>is certainly not what most people would consider as "text", then
>when one reads the executable in "binary" mode, one expects to
>read out the code stream with all the active modifications made to it.
>If one needed to get at the underlying structure (e.g., to add another
>patch) then there were RMS (Record Management Services) calls that
>could be made for that purpose.[/color]

Golly, I'd forgotten all about RMS calls. What a great OS VMS was,
definitely the King of Kings.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Walter Roberson wrote:[color=blue]
>
> There are several operating systems which can transparently compress
> and decompress files. The disk space reported may be the compressed
> file size, or it may be the uncompressed file size -- it varies with
> the OS and the way of asking the question.[/color]

If its transparent (as you say above) it is not relevant to
the discussion.

I repeat. The C runtime should be able to give me back 10 000 'a'
characters after I have written them. If the file is represented
as '10000*a' (7 chars) or as effectively 10 thousand letters
is not relevant. fseek(file,0,SEEK_END) should put me at the
10 000th position, and ftell should return 10 000.
[color=blue]
>
> VMS has a number of different filesystem formats, each aimed at a
> different purpose, and with noticable internal filesystem optimizations
> to suit those different purposes. What you get when you read such files
> in binary mode is not generally the byte-stream stored on disk. For
> example, if you are reading a variable-length record file, when you
> read in binary mode you get the -contents- of the record, not the
> infrastructure bytes that describe the record. This is not a
> "contradiction" in the meaning of "binary" mode, because the other
> standard mode, "text mode" would imply that you are reading text
> whereas the variable-length record might be (say) a struct written as a
> complete object. Binary mode is not necessarily the same as what might
> be termed "raw mode".
>[/color]
Of course but who cares?
If after writing some data I can read it back as a stream of
characters that's all I need to make my algorithm work.

In article <4270120b$0$11678$8fcfb975@news.wanadoo.fr>,
jacob navia <jacob@jacob.remcomp.fr> wrote:[color=blue]
>Walter Roberson wrote:[/color]
[color=blue][color=green]
>> There are several operating systems which can transparently compress
>> and decompress files. The disk space reported may be the compressed
>> file size, or it may be the uncompressed file size -- it varies with
>> the OS and the way of asking the question.[/color][/color]
[color=blue]
>If its transparent (as you say above) it is not relevant to
>the discussion.[/color]

It *is* relevant to the discussion, since you stated that the
size returned by your proposed algorithm should match the size
shown by DIR or ls -l . VMS's relevant command is named DIR .
Also when one is ftp'ing the internal ftp command is named DIR
(ftp clients that provide 'ls' do so by issuing DIR commands.)
Thus in order to know whether the size returned by your proposed
algorithm is "right" or not, one must know what the size returned
by DIR -means-.
[color=blue]
> I repeat. The C runtime should be able to give me back 10 000 'a'
> characters after I have written them.[/color]

That's not a "repeat", that's a new phrasing, which
completely divorces the notion of "file size" from "size shown by"
the directory commands or "the size on disk".

You are now in the circular argument that file size is -defined-
by the value returned by your algorithm. Well of course your
algorithm is "correct" under that definition... the problem is
that your algorithm is -incorrect- under several other valid
interpretations of what "file size" means.

Next time you are on a Unix system, you should try applying
your algorithm to the files /dev/random and /dev/zero --
and you should try applying your definition to the file /dev/null .
What value is going to be returned by ftell() after you write
(LONG_MAX + 1) bytes to /dev/null ? For that matter, what size
is going to be returned by ftell() after you write (LONG_MAX + 1)
bytes to a regular file on a filesystem that supports larger
files? (And yes, such filesystems really truly do exist.
I can write files larger than LONG_MAX on the system I am
using now.)
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

John Smith wrote:[color=blue][color=green]
>>I stand by my comments.[/color]
>
>
> But then again, you're a pompous asshole.
>
>[/color]
Very disturbing to see somebody with my name behave this way on c.l.c.
Please don't confuse me with this guy.

John Smith (the other one)

Christopher Benson-Manica wrote:[color=blue]
>
> copx <invalid@invalid.com> wrote:
>[color=green]
> > I didn't claim that the standard guarantees that it works. However the OP
> > may doesn't care because he wants to solve a practical programming problem
> > not worship sacred texts.[/color]
>
> The OP may also appreciate knowing that your proposed solution is dubious
> at best.
>[color=green]
> > Just because the ISO C standard says something should work in a specific way
> > doesn't mean that it actually works this way in REALITY.[/color]
>
> If something doesn't work the way the ANSI standard says it should,
> the implementation in question is not a C implementation. End of story.[/color]

Does the ANSI standard say that fseek/ftell _only_ work as you described,
or that they are only _guaranteed_ to work as you described? (Relating to
text-vs-binary modes.) In that case, a system which allows ftell() on a
text stream, and non-EOF fseek()s on text streams can still be compatible
with the standard.

On the other hand, I can tell you that MSVC6.0 does _not_ work properly
with ftell() and fseek() in text mode. Specifically, if the file which
is open in text mode uses LF instead of CRLF for line endings, these two
functions return horribly wrong values.

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

In article <d4p6u3$lrd$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
[color=blue]
>Also when one is ftp'ing the internal ftp command is named DIR
>(ftp clients that provide 'ls' do so by issuing DIR commands.)[/color]

Christopher Nehren politely pointed out to me in email that
the internal ftp command is LIST, not DIR. [A related command is NLST --
which isn't DIR either.]
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

Kenneth Brody <kenbrody@spamcop.net> wrote:
[color=blue]
> Does the ANSI standard say that fseek/ftell _only_ work as you described,
> or that they are only _guaranteed_ to work as you described?[/color]

The latter, but I figured concepts such as implementation-defined,
unspecified, and undefined behavior weren't likely to interest the OP.

I do hope my statement wasn't totally out of line...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

John Smith <JSmith@mail.net> wrote:
[color=blue]
> John Smith wrote:[/color]
[ Something. ]
[color=blue]
> John Smith (the other one)[/color]

_The_ other one? Isn't John Smith about the most common name in English?
There must be oodles of men legally using that name, of whom dozens post
to Usenet, I wouldn't be surprised.

Richard

Mark McIntyre <markmcintyre@spamcop.net> wrote:
[color=blue]
> On Wed, 27 Apr 2005 14:19:16 +0200, in comp.lang.c , jacob navia
> <jacob@jacob.remcomp.fr> wrote:
>[color=green]
> >I have never seen a system where setting the file pointer at
> >the end would fail.[/color]
>
> 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.[/color]

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...

Richard

Walter Roberson wrote:[color=blue]
> In article <4270120b$0$11678$8fcfb975@news.wanadoo.fr>,
> jacob navia <jacob@jacob.remcomp.fr> wrote:
>[color=green]
>>I repeat. The C runtime should be able to give me back 10 000 'a'
>>characters after I have written them.[/color]
>
>
> That's not a "repeat", that's a new phrasing, which
> completely divorces the notion of "file size" from "size shown by"
> the directory commands or "the size on disk".
>[/color]


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.

Page 263 Streams.

This is not a "new" phrasing. It is the definition of a stream.
[color=blue]
> Next time you are on a Unix system, you should try applying
> your algorithm to the files /dev/random and /dev/zero --
> and you should try applying your definition to the file /dev/null .
> What value is going to be returned by ftell() after you write
> (LONG_MAX + 1) bytes to /dev/null ? For that matter, what size
> is going to be returned by ftell() after you write (LONG_MAX + 1)
> bytes to a regular file on a filesystem that supports larger
> files? (And yes, such filesystems really truly do exist.
> I can write files larger than LONG_MAX on the system I am
> using now.)[/color]


Those devices are NOT streams as understood by the C language, and
are NOT relevant to this argument.

Richard Bos wrote:[color=blue]
> John Smith <JSmith@mail.net> wrote:
>
>[color=green]
>>John Smith wrote:[/color]
>
> [ Something. ]
>
>[color=green]
>>John Smith (the other one)[/color]
>
>
> _The_ other one? Isn't John Smith about the most common name in English?
> There must be oodles of men legally using that name, of whom dozens post
> to Usenet, I wouldn't be surprised.
>
> Richard[/color]

Johnson is the most common name in English. But sometimes I wish my
mother had named me Boris. I post occasionally to this group, always
asking for advice, never giving it. And I don't call anybody names.

JS

On Thu, 28 Apr 2005 13:45:50 GMT, John Smith
<JSmith@mail.net> wrote:
[color=blue]
> Richard Bos wrote:[color=green]
>> John Smith <JSmith@mail.net> wrote:
>>[color=darkred]
>>>John Smith (the other one)[/color]
>>
>> _The_ other one? Isn't John Smith about the most common name in English?
>> There must be oodles of men legally using that name, of whom dozens post
>> to Usenet, I wouldn't be surprised.[/color]
>
> Johnson is the most common name in English. But sometimes I wish my
> mother had named me Boris. I post occasionally to this group, always
> asking for advice, never giving it. And I don't call anybody names.[/color]

Google Groups turns up several:

One in Italy, one in the Netherlands, one in hr.*, one in aus.*...
A radio amateur
A Doctor Who fan
A pilot
A motorsport fan
...

Of course, several of them might be the same person...

Although both John and Smith are common, the combination John Smith
seems to be quite rare. I've only ever known one personally, and he had
never met another one. Most parents, if they have a common surname like
Smith, don't want to put another common name to it.

The same way that I wouldn't name a real variable foo even if that was
the most descriptive name for it (to be vaguely near some sort of
topic)...

Chris C

In article <5RVbe.1143982$Xk.1085426@pd7tw3no>, John Smith <JSmith@mail.net> writes:[color=blue]
> John Smith wrote:[color=green][color=darkred]
> >>I stand by my comments.[/color]
> >
> > But then again, you're a pompous asshole.
> >[/color]
> Very disturbing to see somebody with my name behave this way on c.l.c.
> Please don't confuse me with this guy.[/color]

'twas an obvious sock puppet; the email address was
<bill.gates@microsoft.com>. Experienced Usenet readers should have
noted that and ignored the message. Inexperienced Usenet readers
might not, but there's nothing to be done about that, except hope
they gain experience.

It's generally best to just ignore this sort of trolling.

--
Michael Wojcik Join Bytes!

Cooperation is just like two pagodas, one hardware and one software.
-- Wen Jiabao