need the file size via windows
Jesse Engle
system. i've been searching for a few hours now on how to do it. any help
appreciated.
--
Jesse Engle
Richard Heathfield
Assuming you don't want to do it the portable way (open it, read every byte,
keep a count), I suggest you ask your question in a newsgroup where your
operating system is on-topic. In your case, that would be:
news:comp.os.ms-windows.programmer.win32
(Chances are good that you'll find that group *extremely* useful, and not
just for this question.)
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
jacob navia
unsigned GetFileSize(char *name)
{
unsigned result=0;
FILE *f = fopen(name,"rb");
if (f) {
fseek(f,0,SEEK_END);
result = ftell(f);
fclose(f);
}
return result;
}
Add error checking as needed.
Richard Heathfield
> #include <stdio.h>
>
> unsigned GetFileSize(char *name)
> {
> unsigned result=0;
> FILE *f = fopen(name,"rb");
> if (f) {
> fseek(f,0,SEEK_END);
"A binary stream need not meaningfully support fseek calls with a whence
value of SEEK_END." (4.9.9.2 of the C89 draft.)
> result = ftell(f);
> fclose(f);
> }
> return result;
> }
>
> Add error checking as needed.
--
jacob navia
"Richard Heathfield" <dont...@address.co.uk.invalid> a écrit dans le
message de news:c2uqaf$5sb$3...@hercules.btinternet.com...
> "A binary stream need not meaningfully support fseek calls with a whence
> value of SEEK_END." (4.9.9.2 of the C89 draft.)
Yes, but I have never seen a compiler under windows that
doesn't support that...
Of course, if in doubt use
http://www.cs.virginia.edu/~lcc-win32
:-)
Irrwahn Grausewitz
[How to determine file size on <some OS>?]
>"Richard Heathfield" <dont...@address.co.uk.invalid> a écrit dans le
>message de news:c2uqaf$5sb$3...@hercules.btinternet.com...
>> "A binary stream need not meaningfully support fseek calls with a whence
>> value of SEEK_END." (4.9.9.2 of the C89 draft.)
>
>Yes, but I have never seen a compiler under windows that
>doesn't support that...
Yeah, whatever, but this statement has no meaning in the context
of c.l.c. Asking questions about specific platforms is almost
always off-topic in c.l.c. The best of an answer one can get
here is either a redirection to a more appropriate place to ask,
or the correct answer in the light of portable C, which in this
case simply is: "No way."
>Of course, if in doubt use
>http://www.cs.virginia.edu/~lcc-win32
>:-)
I know that you know that this is irrelevant. ;-)
Regards
--
Irrwahn Grausewitz (irrw...@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>#include <stdio.h>
>
>unsigned GetFileSize(char *name)
>{
> unsigned result=0;
> FILE *f = fopen(name,"rb");
> if (f) {
> fseek(f,0,SEEK_END);
> result = ftell(f);
> fclose(f);
> }
> return result;
>}
And does this work in a multitasking OS?
Are you sure?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
CBFalconer
> "Richard Heathfield" <dont...@address.co.uk.invalid> a écrit
>>
>>> #include <stdio.h>
>>>
>>> unsigned GetFileSize(char *name)
>>> {
>>> unsigned result=0;
>>> FILE *f = fopen(name,"rb");
>>> if (f) {
>>> fseek(f,0,SEEK_END);
>>
>> a whence value of SEEK_END." (4.9.9.2 of the C89 draft.)
>>
>>> fclose(f);
>>> }
>>> return result;
>>> }
>
> doesn't support that...
>
> Of course, if in doubt use
> http://www.cs.virginia.edu/~lcc-win32
> :-)
Snipped problem code restored. Now install that in some program
such as:
int main(void)
{
printf("Con size = %u\n", GetFileSize("con"));
return 0;
}
compile it with lcc-win32, and run it in its intended
environment. I anticipate failure. Even if ftell happens to
work, the type of result and GetFileSize is not satisfactory.
And, lastly, "under windows" is not apropos to this newsgroup.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
jacob navia
> Snipped problem code restored. Now install that in some program
> such as:
>
> int main(void)
> {
> printf("Con size = %u\n", GetFileSize("con"));
> return 0;
> }
>
> compile it with lcc-win32, and run it in its intended
> environment. I anticipate failure. Even if ftell happens to
> work, the type of result and GetFileSize is not satisfactory.
> And, lastly, "under windows" is not apropos to this newsgroup.
I was not proposing a general utility or library function that
uses isatty() and similar stuff.
It was intended to answer a fairly standard question with
a standard answer. I only used functions in the C99 standard.
Yes, it will fail with "con". (Result from ftell is -1). I said
"add error checking as needed"
For the intended purposes (knowing the size of a disk file)
this function will work without any problems in the OS
we are discussing and under Unix.
nrk
>
> "Richard Heathfield" <dont...@address.co.uk.invalid> a �rit dans le
> message de news:c2uqaf$5sb$3...@hercules.btinternet.com...
>> "A binary stream need not meaningfully support fseek calls with a whence
>> value of SEEK_END." (4.9.9.2 of the C89 draft.)
>
> Yes, but I have never seen a compiler under windows that
> doesn't support that...
>
> Of course, if in doubt use
> http://www.cs.virginia.edu/~lcc-win32
> :-)
I have to disagree with your solution. The right thing to do is to point to
the OP that this is not possible to achieve portably or meaningfully in
standard C, and usually there are better system specific functions that
will do the job for you.
To OP:
This is an FAQ.
http://www.eskimo.com/~scs/C-faq/q19.12.html
I would suggest that you look at system specific solutions. But this is not
the right place to ask about them. Try comp.os.ms-windows.programmer or
some such.
<OT>
Look at FindFirstFile, GetFileSize in the win32 API.
</OT>
-nrk.
--
Remove devnull for email
jacob navia
"nrk" <ram_n...@devnull.verizon.net> a écrit dans le message de
news:_%I4c.99906$6K.2...@nwrddc02.gnilink.net...
> jacob navia wrote:
> I have to disagree with your solution. The right thing to do is to point
to
> the OP that this is not possible to achieve portably or meaningfully in
> standard C, and usually there are better system specific functions that
> will do the job for you.
???
Who cares about system specific functions?
I wrote that in standard C. I use that function since
at least 10 years. Always worked like a charm
from MSDOS to XP, from Unix to OS2.
I wanted to show the OP that simple solutions
exist for this problem, in standard C.
> <OT>
> Look at FindFirstFile, GetFileSize in the win32 API.
> </OT>
GetFileSize needs a file handle, and you got to
call CreateFile, with zig parameters, then
CloseHandle. It returns a 64 bit result however,
what ftell can't do.
Yours is a more system specific answer. .
jacob navia
"CBFalconer" <cbfal...@yahoo.com> a écrit dans le message de
news:405323E2...@yahoo.com...
> Snipped problem code restored. Now install that in some program
> such as:
>
> int main(void)
> {
> printf("Con size = %u\n", GetFileSize("con"));
> return 0;
> }
>
> compile it with lcc-win32, and run it in its intended
> environment. I anticipate failure. Even if ftell happens to
> work, the type of result and GetFileSize is not satisfactory.
This is easily fixed by adding a test for the result of
fseek. Here is a corrected version. Zero sill be returned
for files like the console, and other, probably prn
and other device files.
#include <stdio.h>
unsigned GetFileSize(char *name)
{
unsigned result=0;
FILE *f = fopen(name,"rb");
if (f) {
if ( (fseek(f,0,SEEK_END)) >= 0)
result = ftell(f);
fclose(f);
}
return result;
}
int main(void)
{
printf("Con size = %u\n", GetFileSize("con"));
return 0;
}
This prints zero.
Irrwahn Grausewitz
[attribution restored:]
>CBFalconer <cbfal...@yahoo.com> wrote:
>>
>> Snipped problem code restored. Now install that in some program
>> such as:
>>
>> int main(void)
>> {
>> printf("Con size = %u\n", GetFileSize("con"));
>> return 0;
>> }
>>
>> compile it with lcc-win32, and run it in its intended
>> environment. I anticipate failure. Even if ftell happens to
>> work, the type of result and GetFileSize is not satisfactory.
>> And, lastly, "under windows" is not apropos to this newsgroup.
>
>I was not proposing a general utility or library function that
>uses isatty() and similar stuff.
>It was intended to answer a fairly standard question with
>a standard answer.
Alas, unfortunately, you failed. ;-)
>I only used functions in the C99 standard.
Yes. But you didn't bother to RTFM beforehand: the return type
of ftell is long int, not unsigned int, and ftell returns -1L
on error. Hence your code is not only fairly useless, it is
blatantly wrong:
[...]
JN> unsigned result=0;
JN> FILE *f = fopen(name,"rb");
JN> if (f) {
JN> fseek(f,0,SEEK_END);
JN> result = ftell(f);
[...]
BTW, the other's objections of course still apply, even if the
obvious bug is fixed.
>Yes, it will fail with "con". (Result from ftell is -1). I said
>"add error checking as needed"
This is not a substitute for correct usage of standard
library functions.
>For the intended purposes (knowing the size of a disk file)
>this function will work without any problems in the OS
>we are discussing and under Unix.
We are not discussing OSs here, we are concerned about
portable C code. Yours is not. ;-P
Irrwahn Grausewitz
>
>"nrk" <ram_n...@devnull.verizon.net> a écrit dans le message de
>to
>> the OP that this is not possible to achieve portably or meaningfully in
>> standard C, and usually there are better system specific functions that
>> will do the job for you.
>
>???
!!!
>Who cares about system specific functions?
Everyone who wants to reliably determine the size of a file
on a specific platform, since it cannot be done in a portable
manner using only facilities provided by standard C.
>I wrote that in standard C. I use that function since
>at least 10 years. Always worked like a charm
>from MSDOS to XP, from Unix to OS2.
Oh, c'mon now Jacob, please stop acting as if this is the
first time you're posting here in c.l.c.
>I wanted to show the OP that simple solutions
>exist for this problem, in standard C.
You are still wrong on this issue, and you should know by now.
<snip>
Irrwahn Grausewitz
>
>"CBFalconer" <cbfal...@yahoo.com> a écrit dans le message de
>news:405323E2...@yahoo.com...
>> {
>> printf("Con size = %u\n", GetFileSize("con"));
>> return 0;
>> }
>>
>> compile it with lcc-win32, and run it in its intended
>> environment. I anticipate failure. Even if ftell happens to
>> work, the type of result and GetFileSize is not satisfactory.
>
>This is easily fixed by adding a test for the result of
>fseek. Here is a corrected version. Zero sill be returned
>for files like the console, and other, probably prn
>and other device files.
>
>#include <stdio.h>
>
>unsigned GetFileSize(char *name)
>{
> unsigned result=0;
> FILE *f = fopen(name,"rb");
> if (f) {
> if ( (fseek(f,0,SEEK_END)) >= 0)
> result = ftell(f);
Dang! Oops, you did it again. ;-)
> fclose(f);
> }
> return result;
>}
>
>int main(void)
>{
> printf("Con size = %u\n", GetFileSize("con"));
> return 0;
>}
>
>This prints zero.
And easter and christmas fall on the same date this year. ;-)
jacob navia
"Irrwahn Grausewitz" <irrw...@freenet.de> a écrit dans le message de
news:1nr650tmke46jblgq...@4ax.com...
> >I wrote that in standard C. I use that function since
> >at least 10 years. Always worked like a charm
> >from MSDOS to XP, from Unix to OS2.
>
> Oh, c'mon now Jacob, please stop acting as if this is the
> first time you're posting here in c.l.c.
>
I mean, that function doesn't work?
I have been dreaming then. It is running in most of
my programs since a long time.
I must have some hallucination. Will go to the
doctor. Thanks.
> >I wanted to show the OP that simple solutions
> >exist for this problem, in standard C.
>
> You are still wrong on this issue, and you should know by now.
>
I am always wrong. Even if I propose a function
that I know it works, and everybody else knows.
With just a change of
if (fseek(f,0,SEEK_SET) >= 0)
result = ftell(f);
it will even handle binary files.
Can you please tell me a system where that function
doesn't work?
Or a situation?
Again:
How to read a file size in standard C.
jacob navia
> And easter and christmas fall on the same date this year. ;-)
How deep. How profound. I am impressed.
Richard Heathfield
>
> "Irrwahn Grausewitz" <irrw...@freenet.de> a ecrit dans le message de
> news:1nr650tmke46jblgq...@4ax.com...
>> >I wrote that in standard C. I use that function since
>> >at least 10 years. Always worked like a charm
>> >from MSDOS to XP, from Unix to OS2.
>>
>> Oh, c'mon now Jacob, please stop acting as if this is the
>> first time you're posting here in c.l.c.
>>
>
> I mean, that function doesn't work?
It is not guaranteed to work on all conforming implementations, for reasons
which have already been stated.
> I have been dreaming then. It is running in most of
> my programs since a long time.
There are quite a few void main programs running right now. That doesn't
mean void main is correct.
> With just a change of
> if (fseek(f,0,SEEK_SET) >= 0)
> result = ftell(f);
>
> it will even handle binary files.
No, for reasons that have already been pointed out.
>
> Can you please tell me a system where that function
> doesn't work?
> Or a situation?
If you have the book version of the FAQs, see FAQ 12.40
Irrwahn Grausewitz
>
>"Irrwahn Grausewitz" <irrw...@freenet.de> a écrit dans le message de
>news:1nr650tmke46jblgq...@4ax.com...
>> >I wrote that in standard C. I use that function since
>> >at least 10 years. Always worked like a charm
>> >from MSDOS to XP, from Unix to OS2.
>>
>> Oh, c'mon now Jacob, please stop acting as if this is the
>> first time you're posting here in c.l.c.
>
>I mean, that function doesn't work?
Oh, it works, for a sufficiently off-topic-for-clc definition
of "works".
>I have been dreaming then. It is running in most of
>my programs since a long time.
Then you should rewrite this code, if you're ever going to port
it to yet another platform or be prepared to meet those nasal
demons.
>I must have some hallucination. Will go to the
>doctor. Thanks.
IANADoc, so I cannot comment on this.
>> >I wanted to show the OP that simple solutions
>> >exist for this problem, in standard C.
>>
>> You are still wrong on this issue, and you should know by now.
>>
>
>I am always wrong. Even if I propose a function
>that I know it works, and everybody else knows.
>
>With just a change of
> if (fseek(f,0,SEEK_SET) >= 0)
> result = ftell(f);
>
>it will even handle binary files.
Well done Jacob, you just snipped the faulty declaration of
result! Congratulations. Say, have you been brainwashed by
Edwin Robert Trollsdale, or are you just having a bad day?
;-)
<snip>
>Again:
>
>How to read a file size in standard C.
Again, in capitals: NO WAY!!!
And still, I cannot believe that a knowledgable, respectable
and responsible poster like you happens to have not read the
c.l.c-faq, particularly the answer to before mentioned Q19.12.
CBFalconer
>>>
... snip ...
>>>
>>> compile it with lcc-win32, and run it in its intended
>>> environment. I anticipate failure. Even if ftell happens to
>>> work, the type of result and GetFileSize is not satisfactory.
>>> And, lastly, "under windows" is not apropos to this newsgroup.
>>
>> I was not proposing a general utility or library function that
>> uses isatty() and similar stuff. It was intended to answer a
>> fairly standard question with a standard answer.
>
> Alas, unfortunately, you failed. ;-)
>
>> I only used functions in the C99 standard.
>
> Yes. But you didn't bother to RTFM beforehand: the return type
> of ftell is long int, not unsigned int, and ftell returns -1L
> on error. Hence your code is not only fairly useless, it is
> blatantly wrong:
>
>
> We are not discussing OSs here, we are concerned about
> portable C code. Yours is not. ;-P
At any rate the objection has served its purpose, which is to warn
any dewey eyed newbies that all is not well with such code.
I may be mistaken, but JN seems to have little interest in
bulletproofing his code, which may be why I see so many seemingly
unnecessary bug reports in comp.compilers.lcc, and why I no longer
use it or recommend it to Windoze users. And I may be totally
mistaken.
I have not used lcc-win32 since it began crashing on a 486 in the
debugger, and no correction was ever made AFAICT in spite of
several reports.
Irrwahn Grausewitz
>I may be mistaken, but JN seems to have little interest in
>bulletproofing his code, which may be why I see so many seemingly
>unnecessary bug reports in comp.compilers.lcc, and why I no longer
>use it or recommend it to Windoze users. And I may be totally
>mistaken.
>
>I have not used lcc-win32 since it began crashing on a 486 in the
>debugger, and no correction was ever made AFAICT in spite of
>several reports.
If this is true, it's bad news. Personally, I switched
from lcc-win32 to gcc some years ago, but not because of
QoI-issues, IIRC.
Regards.
jacob navia
> "jacob navia" <ja...@jacob.remcomp.fr> wrote:
> And still, I cannot believe that a knowledgable, respectable
> and responsible poster like you happens to have not read the
> c.l.c-faq, particularly the answer to before mentioned Q19.12.
Q 19.12:
How can I find out the size of a file, prior to reading it in?
[snip other system specific solutions]
Quote:
You can fseek() to the end and then use ftell(),
[snip]
ftell() is not guaranteed
to return a byte count except for binary files.
End Quote.
Since I opened in binary mode, ftell should return the position or
an error, if it is a device file. Testing for that solves any possible
problem. I have used that function in MSDOS, under linux, under
OS2, and under windows since windows 3.0. It has always worked
It is portable, and I have yet to find a system where
that will not work.
nrk
>
> "nrk" <ram_n...@devnull.verizon.net> a �rit dans le message de
> news:_%I4c.99906$6K.2...@nwrddc02.gnilink.net...
>> jacob navia wrote:
>> I have to disagree with your solution. The right thing to do is to point
> to
>> the OP that this is not possible to achieve portably or meaningfully in
>> standard C, and usually there are better system specific functions that
>> will do the job for you.
>
> ???
>
> Who cares about system specific functions?
>
Anyone who programs in the real world that exists outside of CLC. In
particular, the OP seems to be amenable to system specific solutions as
indicated by his question. While your solution might work for OP's current
platform, you've also attached the false guarantee that it is standard and
portable. It is neither. In addition, if we are going for system specific
solutions, why not go for ones that are really designed to work with a
specific system than for a generic alternative that could fail in the
future?
> I wrote that in standard C. I use that function since
> at least 10 years. Always worked like a charm
> from MSDOS to XP, from Unix to OS2.
>
Are you trolling? It is tradition in CLC that we don't care about what
works some of the time or most of the time. We care about what is
*guaranteed* to work according to the ANSI/ISO C Standards. I have never
worked on any machine that wasn't 2's complement with no padding bits, but
I will look like a damn fool if I assert that's the only thing in this
world (the venerable standard tells me that it ain't so).
And in standard C your function is broken:
> #include <stdio.h>
>
> unsigned GetFileSize(char *name)
> {
> unsigned result=0;
> FILE *f = fopen(name,"rb");
> if (f) {
> fseek(f,0,SEEK_END);
This need not have any meaningful behavior. The return can only distinguish
between failure/success of fseek, but "success" needn't have any
particularly useful meaning. Also, you've conveniently omitted error
checking of the return from fseek (that still doesn't fix the fundamental
problem). The bottom line is that the standard does not give you any
useful guarantees about that call. Hence, your solution is to be avoided.
> result = ftell(f);
Huh? ftell returns a long. More importantly, it returns -1L on error. By
using an unsigned int to hold the result you've successfully managed to
prevent any error checking whatsoever on that call (errno could possibly be
useful, but since you didn't set it 0 before the call, that's questionable
too).
> fclose(f);
This should tell you that your so-called "generic" solution might be a
really poor idea. You open the file, seek, find the position and then
close it, all just to find the size of the file. Many (most?) systems
store meta-data on files that make it far easier to retrieve that
information without actually accessing the file. While the end result your
solution might end up doing the same, there's no need for it to. Like I
said, there are good reasons to use system-specific functions, and this
situation is a good candidate to use one, even if the "generic" solution
you offer works (it doesn't).
> }
> return result;
> }
> I wanted to show the OP that simple solutions
> exist for this problem, in standard C.
>
You've managed to clearly illustrate why reading the FAQ is important.
>> <OT>
>> Look at FindFirstFile, GetFileSize in the win32 API.
>> </OT>
>
> GetFileSize needs a file handle, and you got to
> call CreateFile, with zig parameters, then
> CloseHandle. It returns a 64 bit result however,
> what ftell can't do.
>
> Yours is a more system specific answer. .
Yes, and it is IMO the reasonable and better solution to this problem. And
I will refrain from pointing out what FindFirstFile can do (I am sure
you're more than capable of finding out yourself).
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
>
>> I may be mistaken, but JN seems to have little interest in
>> bulletproofing his code, which may be why I see so many seemingly
>> unnecessary bug reports in comp.compilers.lcc, and why I no longer
>> use it or recommend it to Windoze users. And I may be totally
>> mistaken.
>>
>> I have not used lcc-win32 since it began crashing on a 486 in the
>> debugger, and no correction was ever made AFAICT in spite of
>> several reports.
>
> If this is true, it's bad news. Personally, I switched
> from lcc-win32 to gcc some years ago, but not because of
> QoI-issues, IIRC.
Yet the system has some unique advantages for many. It is the
only non-C++ one known to me that provides immediate and
convenient access to the Win32 APIs and dlls.
jacob navia
"CBFalconer" <cbfal...@yahoo.com> a écrit dans le message de
news:40537628...@yahoo.com...
> I have not used lcc-win32 since it began crashing on a 486 in the
> debugger, and no correction was ever made AFAICT in spite of
> several reports.
I have no obligation to fix problems in a 486 without you
getting a maintenance contract.
I do solve most bug reports. But Chuck wants me to:
1) get the 486 of the basement. Re-install windows 95
in a machine with 16MB memory and 2GB disk.
2) Rework the compiler and the debugger to not
use any pentium extensions.
3) See why windows 95 is crashing. Probably a bug
in Microsoft code corrected in later versions since
my debugger runs in other, more recent platforms.
This means at least a whole day of work for a single user.
I have never received any other complaints from
486 users, if they still exist.
Why should I do that?
Chuck doesn't seem to understand this obvious viewpoint.
I am not under any obligation to fix that crash.
And if you do not use lcc-win32 because of your 486
crashing Chuck, it is OK with me. Really.
It is not OK when you start writing however:
<<
JN seems to have little interest in bulletproofing
his code
>>
Because I refuse to spend a day working for you for
free???
What do YOU do for me Chuck?
jacob
nrk
>
> "Irrwahn Grausewitz" <irrw...@freenet.de> a �rit dans le message de
Under Linux, I used your function with a file name ".". It returns 32768,
but I am unable to read even a single byte of those 32768 using fgetc.
What could be wrong? Answer: What I am accessing is not really a "file"
but a kind of, sort of file. 32768 is, kind of, sort of accurate, but it
is not meaningful in terms of "file" contents. System-specific funtions
would've provided me additional information to see that what I was trying
to access was a special kind of "file".
jacob navia
"nrk" <ram_n...@devnull.verizon.net> a écrit dans le message de
news:a%L4c.8057$F9....@nwrddc01.gnilink.net...
> jacob navia wrote:
>
> Under Linux, I used your function with a file name ".". It returns 32768,
> but I am unable to read even a single byte of those 32768 using fgetc.
> What could be wrong?
I do not know but in my RedHat system it returns 4096.
The same as ls -ld ..
Please add the correction I posted. For "special"
files just change
if (fseek(f,0,SEEK_SET) >= 0)
result = ftell(f);
The result obtained (4096) is 100% OK as ls -ld ..
shows
And this function returns the file size. It
doesn't tell you that you will be able to read it
ar wahetever, if you use it with other thing
as a disk file.
>Answer: What I am accessing is not really a "file"
> but a kind of, sort of file. 32768 is, kind of, sort of accurate, but it
> is not meaningful in terms of "file" contents. System-specific funtions
> would've provided me additional information to see that what I was trying
> to access was a special kind of "file".
Maybe. Depends on usage. For my purposes
a simple function without too much OS dependencies
is much more useful than a system spefic one.
In my programs I use it with regular files. And it works
without any problem. I am not designing a bullet
proof GetFileSize function library.
Richard Heathfield
> Q 19.12:
> How can I find out the size of a file, prior to reading it in?
>
> [snip other system specific solutions]
>
> Quote:
>
> You can fseek() to the end and then use ftell(),
> [snip]
The quote continues... "but these tend to have the same problems". That is,
differing line-end representations screw this up for text files...
>
> ftell() is not guaranteed
> to return a byte count except for binary files.
>
> End Quote.
>
> Since I opened in binary mode, ftell should return the position or
> an error, if it is a device file.
...and for binary files, "A binary stream need not meaningfully support
fseek calls with a whence value of SEEK_END" which means the fseek/ftell
trick isn't guaranteed to work.
> Testing for that solves any possible
> problem.
There doesn't appear to be any requirement on implementations to return an
error in the case where SEEK_END isn't meaningfully supported (although I
am very willing to be corrected if I'm wrong about this).
> I have used that function in MSDOS, under linux, under
> OS2, and under windows since windows 3.0. It has always worked
Have you tested it on CP/M? MVS? VM/CMS? MacOS? VMS?
> It is portable, and I have yet to find a system where
> that will not work.
Never forget that some bright spark could release such a system tomorrow,
for all we know.
nrk
>
> "CBFalconer" <cbfal...@yahoo.com> a �rit dans le message de
> news:405323E2...@yahoo.com...
>> Snipped problem code restored. Now install that in some program
>> such as:
>>
>
>> int main(void)
>> {
>> printf("Con size = %u\n", GetFileSize("con"));
>> return 0;
>> }
>>
>> compile it with lcc-win32, and run it in its intended
>> environment. I anticipate failure. Even if ftell happens to
>> work, the type of result and GetFileSize is not satisfactory.
>
> This is easily fixed by adding a test for the result of
> fseek. Here is a corrected version. Zero sill be returned
> for files like the console, and other, probably prn
> and other device files.
>
This correction "improves" the code how?
> #include <stdio.h>
>
> unsigned GetFileSize(char *name)
> {
> unsigned result=0;
> FILE *f = fopen(name,"rb");
> if (f) {
> if ( (fseek(f,0,SEEK_END)) >= 0)
From C99:
The fseek function returns nonzero only for a request that cannot be
satisfied.
Or read correctly, if the return from fseek was zero, then it was
successful, else there was a failure.
Now, you're going to tell me that every system you ever tried it on, it
works. This is like proving the statement "all horses are brown" by
stating the fact that "all horses I have ever seen are brown" :-)
-nrk.
> result = ftell(f);
> fclose(f);
> }
> return result;
> }
>
> int main(void)
> {
> printf("Con size = %u\n", GetFileSize("con"));
> return 0;
> }
>
> This prints zero.
--
Remove devnull for email
Irrwahn Grausewitz
>
>"Irrwahn Grausewitz" <irrw...@freenet.de> a écrit dans le message de
>news:3hs650h7j5281h4ul...@4ax.com...
>> "jacob navia" <ja...@jacob.remcomp.fr> wrote:
>
>> And still, I cannot believe that a knowledgable, respectable
>> and responsible poster like you happens to have not read the
>> c.l.c-faq, particularly the answer to before mentioned Q19.12.
>
>Q 19.12:
>How can I find out the size of a file, prior to reading it in?
>
>[snip other system specific solutions]
>
>Quote:
>
>You can fseek() to the end and then use ftell(),
>[snip]
or maybe try fstat(), but these tend to have the same
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sorts of problems: [...]
^^^^^^^^^^^^^^^^^
</unsnip Q19.12>
BTW, which part of
"A binary stream need not meaningfully support
fseek calls with a whence value of SEEK_END."
(from C99 7.19.9.2.#3)
did you fail to understand?
> ftell() is not guaranteed
> to return a byte count except for binary files.
>
>End Quote.
>
>Since I opened in binary mode, ftell should return the position or
>an error, if it is a device file. Testing for that solves any possible
>problem.
No. Since the fseek part of your "solution" isn't guaranteed
to work as you expect, all bets are off. BTW, IIRC it's not
guaranteed that a text file can successfully be opened in binary
mode (have no C&V handy for that, though; maybe I'm mistaken).
>I have used that function in MSDOS, under linux, under
>OS2, and under windows since windows 3.0. It has always worked
To quote you: "How deep. How profound. I am impressed." ;-)
>It is portable, and I have yet to find a system where
>that will not work.
I'm sure you will find one, if only you try. Or just sit and
wait until your code crashes on some future release of one of
the OSs you mention above.
jacob navia
> BTW, which part of
>
> "A binary stream need not meaningfully support
> fseek calls with a whence value of SEEK_END."
> (from C99 7.19.9.2.#3)
>
> did you fail to understand?
"need not" means "will never" then.
Yes, it "need not" to support fseek calls.
In the real world most do apparently, since I have
never seen that function fail in many OSes
CBFalconer
>> debugger, and no correction was ever made AFAICT in spite of
>> several reports.
>
> I have no obligation to fix problems in a 486 without you
> getting a maintenance contract.
>
>
> And if you do not use lcc-win32 because of your 486
> crashing Chuck, it is OK with me. Really.
>
> It is not OK when you start writing however:
> <<
> JN seems to have little interest in bulletproofing
> his code
> >>
>
> Because I refuse to spend a day working for you for
> free???
>
> What do YOU do for me Chuck?
I never said you had any such obligation. I simply pointed out
that a bug existed, and that I have seen many other seemingly
silly bugs reported, and that in the light of your attitude to
accurate code for measuring file sizes you SEEMED to have little
interest in correctness. Several people have pointed out glaring
flaws, yet you defend the code on the basis of 'it works for me'.
When I originally reported the 486 bug you had made the change
within the past few months, and so finding the problem should have
been fairly easy, but maybe not. In the several years since I
have not whined about it, I have simply not used nor recommended
it. For all I know you may have fixed it.
To me failure to use and/or implement things guaranteed by the
standard is not good. System programs that crash are
automatically buggy.
Irrwahn Grausewitz
>
>"Irrwahn Grausewitz" <irrw...@freenet.de> a écrit dans le message de
>news:ve9750pdplabc46ve...@4ax.com...
>> BTW, which part of
>>
>> "A binary stream need not meaningfully support
>> fseek calls with a whence value of SEEK_END."
>> (from C99 7.19.9.2.#3)
>>
>> did you fail to understand?
>
>"need not" means "will never" then.
No. It means "need not": the library implementor need not
provide sensible support of fseek( fp, 0L, SEEK_END ) for
binary streams, hence you can not rely on its return value.
Simple, isn't it?
>Yes, it "need not" to support fseek calls.
Ah, so?
>In the real world most do apparently, since I have
>never seen that function fail in many OSes
Do you really think with such a claim you can make a point
in a discussion in c.l.c? Do you consider the following
program to be correct, just because it happens to "work"
on many OSs?
int main( void )
{
printf( "Let the demons fly!\n" );
return 0;
}
[BTW, if by "many OSs" you refer to the short list you
presented upthread, then this is just ridiculous.]
Richard Bos
> "nrk" <ram_n...@devnull.verizon.net> a écrit dans le message de
> news:_%I4c.99906$6K.2...@nwrddc02.gnilink.net...
> > I have to disagree with your solution. The right thing to do is to point to
> > the OP that this is not possible to achieve portably or meaningfully in
> > standard C, and usually there are better system specific functions that
> > will do the job for you.
>
> Who cares about system specific functions?
Someone who has a system-specific problem.
> I wrote that in standard C.
No, you didn't. You wrote it in almost, but not quite, Standard C.
> I use that function since at least 10 years. Always worked like a charm
> from MSDOS to XP, from Unix to OS2.
By accident, perhaps.
> I wanted to show the OP that simple solutions exist for this problem, in standard C.
That's what you may have wanted, but you were wrong.
> Yours is a more system specific answer. .
The _problem_ is system-specific.
Richard
Alan Balmer
<ja...@jacob.remcomp.fr> wrote:
>
>Why should I do that?
>
If I were asking myself that question, the answer would be "because
it's an indication that something may be wrong in my code and I want
to find out what, and fix it. After all, the problem may well affect
something else which potentially impacts more than one user."
>Chuck doesn't seem to understand this obvious viewpoint.
>I am not under any obligation to fix that crash.
There are obligations other than contractual.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Alan Balmer
<dont...@address.co.uk.invalid> wrote:
>> Since I opened in binary mode, ftell should return the position or
>> an error, if it is a device file.
>
>...and for binary files, "A binary stream need not meaningfully support
>fseek calls with a whence value of SEEK_END" which means the fseek/ftell
>trick isn't guaranteed to work.
Also, as established a bit ago in a rather long thread involving the
same issue, one may not portably open text files in binary mode. To
quote Dan Pop from that thread, "If you attach a binary stream to a
text file, all the bets are off".
In that thread, I found a statement in the standard which appeared to
justify the practice, but that was adjudged an error in the standard,
and it was pointed out that other parts of the standard contradict it.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
(about whether fseek is meaningful on binary streams
>"need not" means "will never" then.
No, it means "doesn't have to, so you can't rely on it doing so"
>In the real world most do apparently, since I have
>never seen that function fail in many OSes
For definitions of fail that include give the wrong answer, I have. For
instance on at least one OS I've used in the last couple of years, it would
always return a multiple of 512.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
What obligations? Moral ones? Social ones? Come on now.
Jacob is IMHO in the right here. He has no obligation to maintain his code
at all, after all its his, he can do what he likes with it. IF he wants to
fix obscure bugs in versions of the s/w running on long-obsolete hardware,
to please one cranky elder citizen of CLC, then good for him. On the other
hand if he considers that a monumental waste of time compared to adding c99
compliance for his other customers then equally good for him.
CBFalconer
> <alba...@att.net> wrote:
> ><ja...@jacob.remcomp.fr> wrote:
> >
> >> Chuck doesn't seem to understand this obvious viewpoint.
> >> I am not under any obligation to fix that crash.
> >
> > There are obligations other than contractual.
>
> What obligations? Moral ones? Social ones? Come on now.
>
> Jacob is IMHO in the right here. He has no obligation to maintain
> his code at all, after all its his, he can do what he likes with
> it. IF he wants to fix obscure bugs in versions of the s/w running
> on long-obsolete hardware, to please one cranky elder citizen of
> CLC, then good for him. On the other hand if he considers that a
> monumental waste of time compared to adding c99 compliance for his
> other customers then equally good for him.
Hold on there - I never said anything about any obligations. I
reported, he ignored, I abandoned. I am not always cranky, and I
definitely have elders :-)
This came about as a result of M. Navias refusal to treat
non-portable, and seriously flawed, code as such, and his
insistance that that code was perfect because it runs on his
systems. I criticized that after many people had enumerated the
problems, and pointed out historical evidence of failure to attend
to faults. He has absolutely no obligations to me. None. Zero.
Riens. He does appear to be highly sensitive to criticism, real
or perceived.
To return to the subject at hand, here is his flawed code:
>>> #include <stdio.h>
>>>
>>> unsigned GetFileSize(char *name)
>>> {
>>> unsigned result=0;
>>> FILE *f = fopen(name,"rb");
>>> if (f) {
>>> fseek(f,0,SEEK_END);
>>> result = ftell(f);
>>> fclose(f);
>>> }
>>> return result;
>>> }
which M. Navia defends with tenacity.
Alan Balmer
<markmc...@spamcop.net> wrote:
>On Mon, 15 Mar 2004 11:04:11 -0700, in comp.lang.c , Alan Balmer
><alba...@att.net> wrote:
>
>>On Sat, 13 Mar 2004 23:08:12 +0100, "jacob navia"
>><ja...@jacob.remcomp.fr> wrote:
>>
>>>Chuck doesn't seem to understand this obvious viewpoint.
>>>I am not under any obligation to fix that crash.
>>
>>There are obligations other than contractual.
>
>What obligations? Moral ones? Social ones? Come on now.
>
>Jacob is IMHO in the right here. He has no obligation to maintain his code
>at all, after all its his, he can do what he likes with it. IF he wants to
>fix obscure bugs in versions of the s/w running on long-obsolete hardware,
>to please one cranky elder citizen of CLC, then good for him. On the other
>hand if he considers that a monumental waste of time compared to adding c99
>compliance for his other customers then equally good for him.
Just to start, I'll restore the part of my comment that you snipped:
>
>If I were asking myself that question, the answer would be "because
>it's an indication that something may be wrong in my code and I want
>to find out what, and fix it. After all, the problem may well affect
>something else which potentially impacts more than one user."
You are correct - Jacob has no legal obligation to correct his code.
Fortunately, I have no legal obligation to purchase code from an
author who cares that little about his own work and his customers.
Mark McIntyre
<cbfal...@yahoo.com> wrote:
>Mark McIntyre wrote:
>> it. IF he wants to fix obscure bugs in versions of the s/w running
>> on long-obsolete hardware, to please one cranky elder citizen of
>> CLC, then good for him.
>
>Hold on there - I never said anything about any obligations.
indeed you didn't - that was Alan.
>I reported, he ignored, I abandoned. I am not always cranky, and I
>definitely have elders :-)
thats "elder" as in "more experienced" rather than aged. If you prefer....
:-)
>To return to the subject at hand, here is his flawed code:
which I quite agree is erroneous, and doesn't work reliably.
Mark McIntyre
<alba...@att.net> wrote:
>On Mon, 15 Mar 2004 22:46:06 +0000, Mark McIntyre
><markmc...@spamcop.net> wrote:
>
>>On Mon, 15 Mar 2004 11:04:11 -0700, in comp.lang.c , Alan Balmer
>><alba...@att.net> wrote:
>>
>>>There are obligations other than contractual.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>What obligations? Moral ones? Social ones? Come on now.
>>
>>Jacob is IMHO in the right here. He has no obligation to maintain his code
>>at all, after all its his, he can do what he likes with it.
>
>Just to start, I'll restore the part of my comment that you snipped:
And I'll snip it again as I was responding to the above highlighted remark.
>You are correct - Jacob has no legal obligation to correct his code.
Good, but thats not what you referred to, and I objected to .
>Fortunately, I have no legal obligation to purchase code from an
>author who cares that little about his own work and his customers.
You must be awfully hungry, walk everywhere and not use any writing
implements.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>You can fseek() to the end and then use ftell(),
>[snip]
>
>Since I opened in binary mode, ftell should return the position or
>an error, if it is a device file. Testing for that solves any possible
>problem.
>It is portable, and I have yet to find a system where
>that will not work.
Try it on a daemon logfile.