How to get file size?

[Sam]

Hi all,
Is there a function in the standard library that can get the size of a file?
Thank you very much.
Sam.

[copx]

"Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
news:d4**********@reader01.news.esat.net...

Hi all,
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.
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

[Richard Bos]

"copx" <in*****@invalid.com> wrote:

"Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
news:d4**********@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 <mk********************************@4ax.com>.
This should work:

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

Richard

[Richard Bos]

"Sam" <ma*******@hotmail.com> wrote:

Is there a function in the standard library that can get the size of a file?

No, unfortunately not.

Richard

[copx]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

"copx" <in*****@invalid.com> wrote:

"Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
news:d4**********@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 <mk********************************@4ax.com>.

This should work:

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

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

[Ben Pfaff]

"Sam" <ma*******@hotmail.com> writes:

Is there a function in the standard library that can get the size of a file?

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

[Richard Bos]

"copx" <in*****@invalid.com> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

"copx" <in*****@invalid.com> wrote:

"Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
news:d4**********@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 <mk********************************@4ax.com>.

This should work:

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

But it does.

Chapter and verse, please.
The code is actually an almost straight copy form the Quake 2
source.
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.
I mean if it's good enough for ID software it's probably good
enough for everybody.

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

[Eric Sosman]

copx wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

"copx" <in*****@invalid.com> wrote:

"Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
news:d4**********@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 <mk********************************@4ax.com>.

This should work:

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

But it does. The code is actually an almost straight copy form the Quake 2
source. It does work, on Linux and Windows.

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.
Using GCC or multiple Windows
compilers. I mean if it's good enough for ID software it's probably good
enough for everybody.
Yurrgh ...
IMO you're way too academic (i.e. out of touch with programming reality)
here. Where does this NOT work? On the Deathstation 9000?

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.

--
Er*********@sun.com

[copx]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

"copx" <in*****@invalid.com> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

> "copx" <in*****@invalid.com> wrote:
>
>> "Sam" <ma*******@hotmail.com> schrieb im Newsbeitrag
>> news:d4**********@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 <mk********************************@4ax.com>.
>
>> This should work:
>
> No, it shouldn't. ftell() is meaningful only for binary streams,
> fseek()
> to SEEK_END only for text streams.

But it does.

Chapter and verse, please.

This reminds of a theological discussion...

The code is actually an almost straight copy form the Quake 2
source.

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.

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.

I mean if it's good enough for ID software it's probably good
enough for everybody.

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.

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

[Richard Bos]

"copx" <in*****@invalid.com> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> schrieb im Newsbeitrag
news:42***************@news.xs4all.nl...

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.

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

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

[copx]

"Eric Sosman" <er*********@sun.com> schrieb im Newsbeitrag
news:d4**********@news1brm.Central.Sun.COM...
[snip]

But it does. The code is actually an almost straight copy form the Quake
2
source. It does work, on Linux and Windows.

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.

[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

[Walter Roberson]

In article <42***************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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.

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

[Christopher Benson-Manica]

copx <in*****@invalid.com> wrote:

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.
The OP may also appreciate knowing that your proposed solution is dubious
at best.
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.
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.
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.

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.

[Richard Bos]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

In article <42***************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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

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

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

[John Smith]

>

I stand by my comments.

But then again, you're a pompous asshole.

[jacob navia]

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.

[Christopher Benson-Manica]

jacob navia <ja***@jacob.remcomp.fr> wrote:

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

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.

[Eric Sosman]

Christopher Benson-Manica wrote:

jacob navia <ja***@jacob.remcomp.fr> wrote:

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

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

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
es*****@acm-dot-org.invalid

[jacob navia]

Eric Sosman wrote:

Christopher Benson-Manica wrote:

jacob navia <ja***@jacob.remcomp.fr> wrote:

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

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

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

OK Eric at least we agree with that.
... 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.

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

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

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?

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?)

Well, yeah can go :-)

[Jean-Sebastien Samson]

> 1: Open file under binary mode

2: Go to end
3: measure position
4: close
5: return position as file length.

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

[Eric Sosman]

jacob navia wrote:

[...]
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?
The complete text of the question that started this
thread is
Hi all,
Is there a function in the standard library that can get the size of a
file?
Thank you very much.
Sam.

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

--
Er*********@sun.com

[Walter Roberson]

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

File size is the number of bytes you get when reading the stuff
in binary mode.
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.
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.
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.

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.

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?

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

[Mark McIntyre]

On Wed, 27 Apr 2005 14:19:16 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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.
Then your experience is /even more/ limited than I thought.
And the guys throwing nonsense didn't ever show me an example
where this would fail:
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... :-)
I have never seen a system where setting the file pointer at
the end would fail.

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

[Mark McIntyre]

On Wed, 27 Apr 2005 16:08:31 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

File size is the number of bytes you get when reading the stuff
in binary mode.

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

[Mark McIntyre]

On 27 Apr 2005 16:06:57 GMT, in comp.lang.c ,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

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.

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

[jacob navia]

Walter Roberson wrote:

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

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

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.

[Walter Roberson]

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

Walter Roberson wrote:

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.

If its transparent (as you say above) it is not relevant to
the discussion.
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-.
I repeat. The C runtime should be able to give me back 10 000 'a'
characters after I have written them.

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]

John Smith wrote:

I stand by my comments.

But then again, you're a pompous asshole.

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)

[Kenneth Brody]

Christopher Benson-Manica wrote:

copx <in*****@invalid.com> wrote:

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.

The OP may also appreciate knowing that your proposed solution is dubious
at best.

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.

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.

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:Th*************@gmail.com>

[Walter Roberson]

In article <d4**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

Also when one is ftp'ing the internal ftp command is named DIR
(ftp clients that provide 'ls' do so by issuing DIR commands.)

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

[Christopher Benson-Manica]

Kenneth Brody <ke******@spamcop.net> wrote:

Does the ANSI standard say that fseek/ftell _only_ work as you described,
or that they are only _guaranteed_ to work as you described?

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.

[Richard Bos]

John Smith <JS****@mail.net> wrote:

John Smith wrote: [ Something. ]
John Smith (the other one)

_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

[Richard Bos]

Mark McIntyre <ma**********@spamcop.net> wrote:

On Wed, 27 Apr 2005 14:19:16 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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

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

Richard

[jacob navia]

Walter Roberson wrote:

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

I repeat. The C runtime should be able to give me back 10 000 'a'
characters after I have written them.

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

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

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

[John Smith]

Richard Bos wrote:

John Smith <JS****@mail.net> wrote:

John Smith wrote:

[ Something. ]

John Smith (the other one)

_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

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

[Chris Croughton]

On Thu, 28 Apr 2005 13:45:50 GMT, John Smith
<JS****@mail.net> wrote:

Richard Bos wrote:

John Smith <JS****@mail.net> wrote:

John Smith (the other one)

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

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.

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

[Michael Wojcik]

In article <5RVbe.1143982$Xk.1085426@pd7tw3no>, John Smith <JS****@mail.net> writes:

John Smith wrote:

I stand by my comments.

But then again, you're a pompous asshole.

Very disturbing to see somebody with my name behave this way on c.l.c.
Please don't confuse me with this guy.

'twas an obvious sock puppet; the email address was
<bi********@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 mi************@microfocus.com

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

[Default User]

John Smith wrote:

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.

I don't know about English as a whole, but Smith is the most common
surname in the USA, according to census data.


Brian

#! rnews 1144
Xref: xyzzy sci.energy:129236 sci.energy.hydrogen:80066 sci.environment:392849
Newsgroups: sci.environment,sci.energy.hydrogen,sci.energy
Path: xyzzy!nntp
From: "Fred McGalliard" <fr********************@boeing.com>
Subject: Re: Iceland's Hydrogen Buses Zip Toward Oil-Free Economy
X-Nntp-Posting-Host: e056750.nw.nos.boeing.com
Message-ID: <IF********@news.boeing.com>
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Priority: 3
X-Msmail-Priority: Normal
Lines: 9
Sender: nn**@news.boeing.com (Boeing NNTP News Access)
Organization: The Boeing Company
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
References: <11*********************@o13g2000cwo.googlegroups. com> <iP********************@comcast.com> <11**********************@g14g2000cwa.googlegroups .com> <pc*******************@bignews1.bellsouth.net> <11**********************@o13g2000cwo.googlegroups .com> <3d*************@individual.net>
Date: Thu, 28 Apr 2005 16:06:02 GMT
"Don Lancaster" <do*@tinaja.com> wrote in message
news:3d*************@individual.net...
.... Just as avocados are manufactured from water and diesel fuel.
Makes a lousy dip though.
#! rnews 1020
Xref: xyzzy comp.lang.c:555829
Newsgroups: comp.lang.c
Path: xyzzy!nntp
From: "Default User" <fi********@boeing.com.invalid>
Subject: Re: When using select call on many sockets, how to check if one of them is closed
X-Nntp-Posting-Host: pls025033.mw.nos.boeing.com
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <IF********@news.boeing.com>
User-Agent: XanaNews/1.16.3.1
Sender: nn**@news.boeing.com (Boeing NNTP News Access)
Organization: The Boeing Company
References: <11**********************@o13g2000cwo.googlegroups .com>
Mime-Version: 1.0
Date: Thu, 28 Apr 2005 16:06:57 GMT

pr***************@gmail.com wrote:
I am using the select call to read from many sockets. I don't want to
call read on every socket to check if it is closed, as it defeats the
purpose of using the select call.
Is there any way to know whether one of the sockets have been closed,
without actually testing each socket.
From the nature of your question, I'd say comp.unix.programmer is the
newsgroup for you.


Brian
#! rnews 1019
Xref: xyzzy comp.lang.c++:654734
Newsgroups: comp.lang.c++
Path: xyzzy!nntp
From: "Default User" <fi********@boeing.com.invalid>
Subject: Re: OT: is there any way to get rid of "amos"?
X-Nntp-Posting-Host: pls025033.mw.nos.boeing.com
Message-ID: <IF********@news.boeing.com>
User-Agent: XanaNews/1.16.3.1
Sender: nn**@news.boeing.com (Boeing NNTP News Access)
Organization: The Boeing Company
References: <Ky*********************@bgtnsc05-news.ops.worldnet.att.net> <3d*************@individual.net>
Date: Thu, 28 Apr 2005 16:09:06 GMT

lilburne wrote:


Howard wrote:

Is there any way (other than using a kill file) to get rid of this
"amos" jerk? I'm getting awfully tired of seeing all that junk
crap posted here, in what's generally been a fairly "clean"
newsgroup.

I don't see any 'amos' in here. news.individual.net must filter the
spam at source.

I don't see it either, but I may have put the sender into my bozo bin
(its actual name on Xananews) some time back.


Brian

[Thomas Matthews]

Sam wrote:

Hi all,
Is there a function in the standard library that can get the size of a file?
Thank you very much.
Sam.

No, there is not a standard function.
The most portable method is to write a function that
counts all the characters or octects (binary) in
the file.

A more precise method is to use a platform or operating
system function, which is not discussed in this
newsgroup.

Or design your algorithms so that they don't need
to know the size of a file; the function operate
on the data until the end of the file is reached.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[Mark McIntyre]

On Thu, 28 Apr 2005 13:45:50 GMT, in comp.lang.c , John Smith
<JS****@mail.net> wrote:

Johnson is the most common name in English.

In american english. Smith is the most common name in english english.
Many of the american johnsons were originally johannsens and other
names of scandi or germanic origin. Not to mention probably a few
eastern europeans who got randomly named by customs officials too lazy
to spell the real word.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Thu, 28 Apr 2005 06:37:40 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

On Wed, 27 Apr 2005 14:19:16 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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

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

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

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

[Default User]

Mark McIntyre wrote:

On Thu, 28 Apr 2005 13:45:50 GMT, in comp.lang.c , John Smith
<JS****@mail.net> wrote:

Johnson is the most common name in English.

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]

In article <11**********************@l41g2000cwc.googlegroups .com>, "Default User" <de***********@yahoo.com> writes:

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

--
Michael Wojcik mi************@microfocus.com

[Jack Klein]

On Wed, 27 Apr 2005 14:19:16 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote in comp.lang.c:

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...
I think the best thing to do is to ignore this guys.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Thu, 28 Apr 2005 09:54:57 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote in comp.lang.c:

Walter Roberson wrote:

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

I repeat. The C runtime should be able to give me back 10 000 'a'
characters after I have written them.

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

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?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Keith Thompson]

Jack Klein <ja*******@spamcop.net> writes:

On Wed, 27 Apr 2005 14:19:16 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote in comp.lang.c:

[...]

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Keith Thompson wrote:

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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Joe Wright]

Jack Klein wrote:

On Wed, 27 Apr 2005 14:19:16 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote in comp.lang.c:

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

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

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.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Joe Wright wrote:

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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Stephen Sprunk]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d4**********@canopus.cc.umanitoba.ca...

In article <42***************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov