Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > how can i find the size of a binary file

Reply
Thread Tools

how can i find the size of a binary file

 
 
Roberto Waltman
Guest
Posts: n/a
 
      11-13-2011
jacob navia wrote:
Nobody a écrit :

>> CP/M records the size of a file in sectors rather than in bytes. Text
>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>> was inherited by DOS and then Windows).

>
>This is not true at least for the last 20 years for MSDOS
>and windows...


Unfortunately (I consider this to be a mistake) it is still true.
The C# language still recognizes CTRL-Z as a valid EOF marker. (As
part of the language specification)
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      11-14-2011
On Nov 12, 1:46*am, Barry Schwarz <(E-Mail Removed)> wrote:
> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <(E-Mail Removed)>
> wrote:
>
>
>
>
>
> >mark <(E-Mail Removed)> writes:
> >> thanks for any help

>
> >Please include the question in the body of your post.

>
> >"how can i find the size of a binary file"

>
> ><There is no reliable way to do this in portable standard C. *You can
> >read through the file, adding up how many bytes you've read, but
> >that's both slow and not 100% reliable. *An implementation is allowed
> >to treat a binary file as if it had some implementation-defined
> >number of null bytes append to it (C99 7.19.2p3), though I don't
> >know of any implementations that actually do that.

>
> >You can open the file (in binary mode), then fseek() to the end of
> >it, then use ftell() to get the current position. *That's *usually*

>
> From 7.19.9.2-3: "A binary stream need not meaningfully support fseek
> calls with a whence value of SEEK_END."


why do you keep doing this? What is your point?

<snip>
 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      11-15-2011
On Mon, 14 Nov 2011 01:21:31 -0800 (PST), Nick Keighley
<(E-Mail Removed)> wrote:

>On Nov 12, 1:46*am, Barry Schwarz <(E-Mail Removed)> wrote:
>> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <(E-Mail Removed)>
>> wrote:
>>
>>
>>
>>
>>
>> >mark <(E-Mail Removed)> writes:
>> >> thanks for any help

>>
>> >Please include the question in the body of your post.

>>
>> >"how can i find the size of a binary file"

>>
>> ><There is no reliable way to do this in portable standard C. *You can
>> >read through the file, adding up how many bytes you've read, but
>> >that's both slow and not 100% reliable. *An implementation is allowed
>> >to treat a binary file as if it had some implementation-defined
>> >number of null bytes append to it (C99 7.19.2p3), though I don't
>> >know of any implementations that actually do that.

>>
>> >You can open the file (in binary mode), then fseek() to the end of
>> >it, then use ftell() to get the current position. *That's *usually*

>>
>> From 7.19.9.2-3: "A binary stream need not meaningfully support fseek
>> calls with a whence value of SEEK_END."

>
>why do you keep doing this? What is your point?


People keep recommending an approach which may or may not work and for
which there is no requirement that the implementation document whether
it does or not. I'm pretty sure the OP has long abandoned the thread
but it would be a disservice to those who follow the frequent advice
to search the archives to allow a questionable recommendation to stand
without some qualification.

--
Remove del for email
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      11-15-2011
On Mon, 14 Nov 2011 18:18:05 +0100, "io_x" <(E-Mail Removed)> wrote:

>"Barry Schwarz" <(E-Mail Removed)> ha scritto nel messaggio
>news:(E-Mail Removed).. .
>> On Fri, 11 Nov 2011 22:59:06 +0100, jacob navia <(E-Mail Removed)>
>> wrote:
>>> if (result) {
>>> fread(result,1,siz,f);

>> There is no guarantee that fread will actually read all the bytes
>> requested. How can the user determine this?

>
>i agree with Barry Schwarz on above.
>on "How can the user determine this?" : the user can find the second time
>the size is the same: if it is the same ok copy in the other case return error.
>the wrong is i know what contain file in the time t° but not in the time t'>t°
>and suppose no change of file for time >t°.


Your response makes no sense. What second time?

The point I was trying to make was that one should examine the return
from fread.

--
Remove del for email
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      11-15-2011
On Nov 15, 4:55*am, Barry Schwarz <(E-Mail Removed)> wrote:
> On Mon, 14 Nov 2011 01:21:31 -0800 (PST), Nick Keighley
>
>
>
>
>
> <(E-Mail Removed)> wrote:
> >On Nov 12, 1:46*am, Barry Schwarz <(E-Mail Removed)> wrote:
> >> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <(E-Mail Removed)>
> >> wrote:

>
> >> >mark <(E-Mail Removed)> writes:
> >> >> thanks for any help

>
> >> >Please include the question in the body of your post.

>
> >> >"how can i find the size of a binary file"

>
> >> ><There is no reliable way to do this in portable standard C. *You can
> >> >read through the file, adding up how many bytes you've read, but
> >> >that's both slow and not 100% reliable. *An implementation is allowed
> >> >to treat a binary file as if it had some implementation-defined
> >> >number of null bytes append to it (C99 7.19.2p3), though I don't
> >> >know of any implementations that actually do that.

>
> >> >You can open the file (in binary mode), then fseek() to the end of
> >> >it, then use ftell() to get the current position. *That's
> >> >*usually*


did you miss the "*usually*"?


> >> From 7.19.9.2-3: "A binary stream need not meaningfully support fseek
> >> calls with a whence value of SEEK_END."

>
> >why do you keep doing this? What is your point?

>
> People keep recommending an approach which may or may not work


so saying it once seems fine.


> and for
> which there is no requirement that the implementation document whether
> it does or not.


but i also suspect it works on very many systems. Unix and Windows?

> *I'm pretty sure the OP has long abandoned the thread
> but it would be a disservice to those who follow the frequent advice
> to search the archives to allow a questionable recommendation to stand
> without some qualification.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-15-2011
On 11/15/2011 03:41 AM, Nick Keighley wrote:
> On Nov 15, 4:55�am, Barry Schwarz <(E-Mail Removed)> wrote:

....
>> People keep recommending an approach which may or may not work

>
> so saying it once seems fine.


Once per contrary recommendation, yes. Doing it only once in a thread
where the same recommendation has been made multiple times might not be
sufficient warning for people who are only skimming the thread.
--
James Kuyper
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      11-19-2011
On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:

>> CP/M records the size of a file in sectors rather than in bytes. Text
>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>> was inherited by DOS and then Windows).

>
> This is not true at least for the last 20 years for MSDOS
> and windows...


It remains true to this day.

If you use fopen() to open a file in text mode (i.e. with the "t" flag, or
without the "b" flag when _fmode is _O_TEXT), a ^Z character will be
treated as an EOF marker (i.e. fgetc() will return EOF upon reading this
character).

Reference:

http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx

Or you could have just compiled a 5-line test program.

 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-19-2011
On 2011-11-19, Nobody <(E-Mail Removed)> wrote:
> On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:
>
>>> CP/M records the size of a file in sectors rather than in bytes. Text
>>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>>> was inherited by DOS and then Windows).

>>
>> This is not true at least for the last 20 years for MSDOS
>> and windows...

>
> It remains true to this day.
>
> If you use fopen() to open a file in text mode (i.e. with the "t" flag, or


You don't have to use the C library to see that there is a problem. Just
use the utilities that come with Windows. I just tried this on Windows 7:

C:\>copy con file
asdf


Now the file has no Ctrl-Z in it. It is 6 bytes long "asdf\r\n".
So far so good, right?

But now use a binary editor to insert a ctrl-Z as the first character
of the file:

C:\> type file

nothing!

C:\> copy file con

nothing!

But if we load the file in Notepad, we see everything and the Ctrl-Z shows as a
graphical character.

These clowns still haven't figured out a consistent representation of text
files that holds across their operating system.

But then, look, the idiotic drive letter is still there, so what do you expect.
 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      11-19-2011
Kaz Kylheku wrote:
) But then, look, the idiotic drive letter is still there, so what do you expect.

26 different drives should be enough for everybody!

(I run into a drive letter shortage at work all the time, so yeah...)


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-19-2011
Kaz Kylheku <(E-Mail Removed)> writes:
> On 2011-11-19, Nobody <(E-Mail Removed)> wrote:
>> On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:
>>
>>>> CP/M records the size of a file in sectors rather than in bytes. Text
>>>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>>>> was inherited by DOS and then Windows).
>>>
>>> This is not true at least for the last 20 years for MSDOS
>>> and windows...

>>
>> It remains true to this day.
>>
>> If you use fopen() to open a file in text mode (i.e. with the "t" flag, or

>
> You don't have to use the C library to see that there is a problem. Just
> use the utilities that come with Windows.

[snip]

No, but you do have to use the C library to show that there's a problem
that's relevant to the current discussion and to this newsgroup.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Preferred Size, Minimum Size, Size Jason Cavett Java 5 05-25-2008 08:32 AM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
Can some one Explain How To Find File and Leech them Accully How to find all Articals Related to that binary callejachris@tpg.com.au Computer Support 2 12-04-2005 02:15 PM
Getting file size of binary file Arnold C Programming 17 01-31-2004 04:29 AM



Advertisments