Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13122 > unrolled thread

how can i find the size of a binary file

Back to article view | Back to comp.lang.c

Contents

  how can i find the size of a binary file mark <nospam@nospam.com> - 2011-11-11 21:37 +0000
    Re: how can i find the size of a binary file John Gordon <gordon@panix.com> - 2011-11-11 21:48 +0000
      Re: how can i find the size of a binary file mark <nospam@nospam.com> - 2011-11-11 21:53 +0000
        Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-11 23:00 +0100
        Re: how can i find the size of a binary file James Kuyper <jameskuyper@verizon.net> - 2011-11-11 17:20 -0500
          Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 15:15 -0800
          Re: how can i find the size of a binary file Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-12 12:43 +0200
        Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 14:25 -0800
    Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-11 22:59 +0100
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
        Re: how can i find the size of a binary file "io_x" <a@b.c.invalid> - 2011-11-14 18:18 +0100
          Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-14 20:55 -0800
    Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 14:03 -0800
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
        Re: how can i find the size of a binary file Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 01:21 -0800
          Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-14 20:55 -0800
            Re: how can i find the size of a binary file Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:41 -0800
              Re: how can i find the size of a binary file James Kuyper <jameskuyper@verizon.net> - 2011-11-15 06:53 -0500
      Re: how can i find the size of a binary file Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-13 02:23 +0100
      Re: how can i find the size of a binary file Nobody <nobody@nowhere.com> - 2011-11-13 02:47 +0000
        Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-13 08:44 +0100
          Re: how can i find the size of a binary file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-13 12:31 +0000
          Re: how can i find the size of a binary file Roberto Waltman <usenet@rwaltman.com> - 2011-11-13 10:31 -0500
          Re: how can i find the size of a binary file Nobody <nobody@nowhere.com> - 2011-11-19 07:37 +0000
            Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-19 17:54 +0000
              Re: how can i find the size of a binary file Willem <willem@toad.stack.nl> - 2011-11-19 18:18 +0000
              Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 14:19 -0800
                Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-20 01:14 +0000
                  Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 21:41 -0800
                    Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-20 05:52 +0000
                      Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 22:23 -0800
          Re: how can i find the size of a binary file David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
    Re: how can i find the size of a binary file blp@cs.stanford.edu (Ben Pfaff) - 2011-11-11 14:32 -0800
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
    Re: how can i find the size of a binary file Ike Naar <ike@sverige.freeshell.org> - 2011-11-11 22:41 +0000
    Re: how can i find the size of a binary file "BartC" <bc@freeuk.com> - 2011-11-13 12:32 +0000
      Re: how can i find the size of a binary file "BartC" <bc@freeuk.com> - 2011-11-13 14:56 +0000

Page 1 of 2  [1] 2  Next page →

#13122 — how can i find the size of a binary file

thanks for any help

[toc] | [next] | [standalone]

#13123

In <j9k4i8$tah$1@speranza.aioe.org> mark <nospam@nospam.com> writes:

> thanks for any help

Call fread() in a loop and keep track of how many total bytes were read.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#13125

> In <j9k4i8$tah$1@speranza.aioe.org> mark <nospam@nospam.com> writes:
> 
>> thanks for any help
> 
> Call fread() in a loop and keep track of how many total bytes were read.

thanks for ur answer but this will b very inefficent, my question is - 
what is the builtin filesize function in c

thnx

[toc] | [prev] | [next] | [standalone]

#13129

Le 11/11/11 22:53, mark a écrit :
>> In<j9k4i8$tah$1@speranza.aioe.org>  mark<nospam@nospam.com>  writes:
>>
>>> thanks for any help
>>
>> Call fread() in a loop and keep track of how many total bytes were read.
>
> thanks for ur answer but this will b very inefficent, my question is -
> what is the builtin filesize function in c
>
> thnx

See my reply in this same thread.

[toc] | [prev] | [next] | [standalone]

#13134

On 11/11/2011 04:53 PM, mark wrote:
>> In <j9k4i8$tah$1@speranza.aioe.org> mark <nospam@nospam.com> writes:
>>
>>> thanks for any help
>>
>> Call fread() in a loop and keep track of how many total bytes were read.
> 
> thanks for ur answer but this will b very inefficent, my question is - 
> what is the builtin filesize function in c

There isn't one. That was considered to be too OS-dependent to justify
standardizing it. For example, on some operating systems, the only thing
that you can quickly determine is how much space has been allocated to
store a file; how much of that space has actually been used can only be
determined by some procedure equivalent to the fread() method given
above. POSIX provides stat(), lstat(), and fstat(); other OSs provide
other methods.

One approach that works on many systems is fseek(file, 0, SEEK_END)
followed by ftell(file). However, make sure to check for an error return
from fseek() - "A binary stream need not meaningfully support fseek
calls with a whence value of SEEK_END." (7.19.9.2p3).

An extended discussion started the last time someone asked something
like this. A popular contention was that it's pointless to ask how big a
file is, because at best, the answer you'll get is how big it was at
some time in the past; it might be a different size now. That point of
view has some validity, but it ignores two things:

1. You might be explicitly looking for the current value of a time
dependent quantity, such as keeping track of how fast a file is growing.

2. You might have done something to make sure that the file shouldn't
change in size. This is extremely common, in my experience. There's
often only one unprivileged userid currently authorized to change a
given file. If that userid is mine, it's reasonably safe to assume that
if I'm not currently changing the file, it's size won't change.

[toc] | [prev] | [next] | [standalone]

#13148

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> An extended discussion started the last time someone asked something
> like this. A popular contention was that it's pointless to ask how big a
> file is, because at best, the answer you'll get is how big it was at
> some time in the past; it might be a different size now. That point of
> view has some validity, but it ignores two things:
>
> 1. You might be explicitly looking for the current value of a time
> dependent quantity, such as keeping track of how fast a file is growing.
>
> 2. You might have done something to make sure that the file shouldn't
> change in size. This is extremely common, in my experience. There's
> often only one unprivileged userid currently authorized to change a
> given file. If that userid is mine, it's reasonably safe to assume that
> if I'm not currently changing the file, it's size won't change.

Agreed.  But even so, your code should probably be robust enough that it
doesn't blow up in your face if the file size *has* changed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13174

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/11/2011 04:53 PM, mark wrote:
> >> In <j9k4i8$tah$1@speranza.aioe.org> mark <nospam@nospam.com> writes:
> >>
> >>> thanks for any help
> >>
> >> Call fread() in a loop and keep track of how many total bytes were read.
> > 
> > thanks for ur answer but this will b very inefficent, my question is - 
> > what is the builtin filesize function in c
> 
> There isn't one. That was considered to be too OS-dependent to justify
> standardizing it. For example, on some operating systems, the only thing
> that you can quickly determine is how much space has been allocated to
> store a file; how much of that space has actually been used can only be
> determined by some procedure equivalent to the fread() method given
> above. POSIX provides stat(), lstat(), and fstat(); other OSs provide
> other methods.
> 
> One approach that works on many systems is fseek(file, 0, SEEK_END)
> followed by ftell(file). However, make sure to check for an error return
> from fseek() - "A binary stream need not meaningfully support fseek
> calls with a whence value of SEEK_END." (7.19.9.2p3).
> 
> An extended discussion started the last time someone asked something
> like this. A popular contention was that it's pointless to ask how big a
> file is, because at best, the answer you'll get is how big it was at
> some time in the past; it might be a different size now. That point of
> view has some validity, but it ignores two things:
> 
> 1. You might be explicitly looking for the current value of a time
> dependent quantity, such as keeping track of how fast a file is growing.
> 
> 2. You might have done something to make sure that the file shouldn't
> change in size. This is extremely common, in my experience. There's
> often only one unprivileged userid currently authorized to change a
> given file. If that userid is mine, it's reasonably safe to assume that
> if I'm not currently changing the file, it's size won't change.

And some day in the future someone might even invent read-only media, 
such that it's physically impossible for the file, and thus its size,
to be changed.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#13136

mark <nospam@nospam.com> writes:
>> In <j9k4i8$tah$1@speranza.aioe.org> mark <nospam@nospam.com> writes:
>> 
>>> thanks for any help
>> 
>> Call fread() in a loop and keep track of how many total bytes were read.
>
> thanks for ur answer but this will b very inefficent, my question is - 
> what is the builtin filesize function in c
>
> thnx

I think you mean:

> Thanks for your answer, but this will be very inefficient.  My question is,
> what is the builtin file size function in C?
>
> Thanks.

If you take the time to spell out words, it will make it easier for the
rest of us to read what you have to say (especially those for whom
English is not a first language) and will generally make us more
inclined to help you.

In answer to your question, there is none; see my other followup for
details.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13127

Le 11/11/11 22:37, mark a écrit :
> thanks for any help

This function figures out the size of a file, allocates a buffer
and returns the contents of the file.


#include <stdio.h>
#include <stdlib.h>
char *FileToRam(char *fname)
{
         FILE *f = fopen(fname,"rb");
         long siz;
         char *result;
         if (f == NULL)
                 return NULL;
	/* Position yourself at the end of the file,
	   then get the current position. This gives
	   you the current position in all systems
	   except in the DS 9000 or if the file is
	   longer than what a long can hold */
         fseek(f,0,SEEK_END);
         siz = ftell(f);
         fseek(f,0,SEEK_SET);
	/* Now allocate a buffer, fill it and
	   return it.
         result = calloc(1,siz+1);
         if (result) {
         	fread(result,1,siz,f);
	}
         fclose(f);
         return result;
}

[toc] | [prev] | [next] | [standalone]

#13161

On Fri, 11 Nov 2011 22:59:06 +0100, jacob navia <jacob@spamsink.net>
wrote:

>Le 11/11/11 22:37, mark a écrit :
>> thanks for any help
>
>This function figures out the size of a file, allocates a buffer
>and returns the contents of the file.
>
>
>#include <stdio.h>
>#include <stdlib.h>
>char *FileToRam(char *fname)
>{
>         FILE *f = fopen(fname,"rb");
>         long siz;
>         char *result;
>         if (f == NULL)
>                 return NULL;
>	/* Position yourself at the end of the file,
>	   then get the current position. This gives
>	   you the current position in all systems
>	   except in the DS 9000 or if the file is

I wonder how long it took you to test on all the non-DS9000 systems.

>	   longer than what a long can hold */
>         fseek(f,0,SEEK_END);

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

>         siz = ftell(f);
>         fseek(f,0,SEEK_SET);
>	/* Now allocate a buffer, fill it and
>	   return it.
>         result = calloc(1,siz+1);

Why spend the time initializing a block of memory that will have all
its bytes immediately replaced with new values?  

Since it is a binary file, what is the value of appending a '\0' at
the end?  It is not likely that the file can be treated as a string.

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

>	}
>         fclose(f);
>         return result;
>}

 Just because you could not allocate enough memory to hold the entire
file does not eliminate the OP's need to know the length of the file.
But then you never tell him that anyway.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#13295

"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio
news:8iirb790d9ahb39cprham1dthlo90jcmg6@4ax.com...
> On Fri, 11 Nov 2011 22:59:06 +0100, jacob navia <jacob@spamsink.net>
> 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°.

[toc] | [prev] | [next] | [standalone]

#13353

On Mon, 14 Nov 2011 18:18:05 +0100, "io_x" <a@b.c.invalid> wrote:

>"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio
>news:8iirb790d9ahb39cprham1dthlo90jcmg6@4ax.com...
>> On Fri, 11 Nov 2011 22:59:06 +0100, jacob navia <jacob@spamsink.net>
>> 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

[toc] | [prev] | [next] | [standalone]

#13130

mark <nospam@nospam.com> 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*
going to be the size of the file, but it's still not 100% portable
for the reasons stated above.  Furthermore, ftell() returns a long
int; if long int is 32 bits on your system, it's not going to work
for files that are 2 GiB or bigger.

Your operating system probably provides a way to get this information
directly.  On Unix-like systems, stat() does this ("man 2 stat"
for details).  On other systems, consult your documentation or ask
in a system-specific forum.

This happens to be one of those things that's much easier to do in
a system-specific way than by using portable C.

And watch out for race conditions.  Whatever method you use will tell you
the size of the file at the moment when you did the query.  The file can
grow, shrink, or even vanish between that and the time when try to do
something with the information.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13162

On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>mark <nospam@nospam.com> 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."

>going to be the size of the file, but it's still not 100% portable
>for the reasons stated above.  Furthermore, ftell() returns a long
>int; if long int is 32 bits on your system, it's not going to work
>for files that are 2 GiB or bigger.
>
>Your operating system probably provides a way to get this information
>directly.  On Unix-like systems, stat() does this ("man 2 stat"
>for details).  On other systems, consult your documentation or ask
>in a system-specific forum.
>
>This happens to be one of those things that's much easier to do in
>a system-specific way than by using portable C.
>
>And watch out for race conditions.  Whatever method you use will tell you
>the size of the file at the moment when you did the query.  The file can
>grow, shrink, or even vanish between that and the time when try to do
>something with the information.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#13266

On Nov 12, 1:46 am, Barry Schwarz <schwa...@dqel.com> wrote:
> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>
>
>
>
>
> >mark <nos...@nospam.com> 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>

[toc] | [prev] | [next] | [standalone]

#13352

On Mon, 14 Nov 2011 01:21:31 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>On Nov 12, 1:46 am, Barry Schwarz <schwa...@dqel.com> wrote:
>> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <ks...@mib.org>
>> wrote:
>>
>>
>>
>>
>>
>> >mark <nos...@nospam.com> 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

[toc] | [prev] | [next] | [standalone]

#13357

On Nov 15, 4:55 am, Barry Schwarz <schwa...@dqel.com> wrote:
> On Mon, 14 Nov 2011 01:21:31 -0800 (PST), Nick Keighley
>
>
>
>
>
> <nick_keighley_nos...@hotmail.com> wrote:
> >On Nov 12, 1:46 am, Barry Schwarz <schwa...@dqel.com> wrote:
> >> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson <ks...@mib.org>
> >> wrote:
>
> >> >mark <nos...@nospam.com> 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.

[toc] | [prev] | [next] | [standalone]

#13376

On 11/15/2011 03:41 AM, Nick Keighley wrote:
> On Nov 15, 4:55�am, Barry Schwarz <schwa...@dqel.com> 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

[toc] | [prev] | [next] | [standalone]

#13222

Keith Thompson ha scritto:
> mark<nospam@nospam.com>  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"
>

Keith answered in a wonderful way. You may want to read the following
article on the same topic (there is also a "compliant solution" that
works on both Posix and Windows systems - it uses the fstat() function):
http://goo.gl/IKHvE

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [next] | [standalone]

#13224

On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson wrote:

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

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). Binary files need their own
mechanism for determining where the data ends and the padding begins.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web