Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > file of exact size

Reply
Thread Tools

file of exact size

 
 
Charlie Gordon
Guest
Posts: n/a
 
      09-15-2007
"Wade Ward" <(E-Mail Removed)> a écrit dans le message de news:
http://www.velocityreviews.com/forums/(E-Mail Removed)...
>
> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-gordon.me.uk...
>> Wade Ward wrote, On 15/09/07 11:13:
>>> "Flash Gordon" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)-gordon.me.uk...

>
>>>> It may, of course, be possible to create such a file using purely
>>>> standard C by, for example, creating the file and writing that number
>>>> of characters.
>>> OP just dug up K&R2. I think this is easily within the realm of ISO C.

>>
>> I stated that it was potentially possible and even one way it could be
>> done in ISO C so I don't see what you are getting at here, unless you
>> were posting to agree with me.
>>
>> Depending on what is really wanted there may well be a better way to
>> achieve it, such as using sparse files, but it all depends on the real
>> requirements and the system in question. I certainly would not want to
>> wait whilst such a file was written.

> Yeah, well, I let Heathfield's program run for about fifteen minutes. I'm
> missing something and my IQ isn't getting bigger tonight, so I'll let it
> rest.
>
> The benchmark to beat is eight minutes. Sleep on it.
>
> unsigned long wait = 2282899UL;
> fputs("please wait\n", stderr);
> while(!errupt && wait--)
> {
> unsigned int erest = 1123;
> while(!errupt && erest--)
>
> Tja.


given todays average harware performance, 1 minute seems a good goal for
this benchmark.
using fwrite with a decent buffer size should do it.

--
Chqrlie.


 
Reply With Quote
 
 
 
 
Michal Nazarewicz
Guest
Posts: n/a
 
      09-15-2007
> "Michal Nazarewicz" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)86.com...
>> "Wade Ward" <(E-Mail Removed)> writes:
>>
>>> How do I use the C Programming Language to create a files that is
>>> 2563695577 bytes.

>>
>> I believe it is platform dependent question. Consult your operating
>> system's newsgroup. 2563695577 is more then a maximum value of a 32-bit
>> integer number and therefore some systems may have problems operating on
>> such files (in fact, in some situations it may be impossible to do
>> because of file system's limitations) unless you compile your program in
>> special way (ie. in Unix you'd compile your program in such a way that
>> it'll use 64-bit file offsets instead of 32-bit). But as I've said it
>> is all implementation specific.


"Wade Ward" <(E-Mail Removed)> writes:
> I think if I knocked off 90% of the number in the original post, I would be
> within 32 bits, but I don't think that part of it is important.


It may be important. In fact it is. If file systems holds file size as
a 32-bit signed number (not very clever) you won't be able to create
file greater then 2^31-1. If it's 32-bit unsigned number then instead
the limit is 2^32-1. But hey! File system may hold file size as a 24-bit
unsigned number in which case you won't be able to create file greater
then 16 MiB.

> Let's say, instead, that you want to create a thousand files of size 10^8
> bytes. The implementation-specific part, how your machine or platform
> represents EOF, is much smaller than the files in question.


Uhm? Don't understand the part about representing EOF... From what
I know EOF is usually not represented in any way -- instead file system
holds number of bytes file contains (at least if we are talking about
files).

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      09-15-2007
Charlie Gordon said:

<snip>

> If the test succeeds, the file produced on a Windows system by
> redirecting stdout to a new file will likely be twice the size wanted.


<shrug> A broken OS is indeed one possible obstacle to producing the
file as specified. There are other obstacles too, some of them rather
more difficult to overcome.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      09-15-2007
"Richard Heathfield" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> Charlie Gordon said:
>
> <snip>
>
>> If the test succeeds, the file produced on a Windows system by
>> redirecting stdout to a new file will likely be twice the size wanted.

>
> <shrug> A broken OS is indeed one possible obstacle to producing the
> file as specified. There are other obstacles too, some of them rather
> more difficult to overcome.


The new-line translation issue is easy to solve: insteal of stdout, we need
to use a stream opened in binary mode. FILE *fp = fopen("bigfile", "wb");
Writing the appropriate number of bytes to fp should produce a file with the
appropriate size...
- if the OS can handle that size,
- and the file system can too,
- and there is enough available space,
- and there are no write errors,
- and we let the program run to completion,
- and "bigfile" is a regular file name (as opposed to some OS specific
device or pipe name),
- and the program can create the file,
- and it can write to the file system
- and some other program does not mess with the file
- ...

Note also that some OSes have system specific functions to truncate or
extend files to a certain size, POSIX has two that you might find useful,
but further discussing these is off topic in this forum:

#include <unistd.h>
#include <sys/types.h>

int truncate(const char *path, off_t length);
int ftruncate(int fd, off_t length);

--
Chqrlie.


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      09-15-2007
In article <46ec0dc9$0$31752$(E-Mail Removed)>,
Charlie Gordon <(E-Mail Removed)> wrote:
>The new-line translation issue is easy to solve: insteal of stdout, we need
>to use a stream opened in binary mode. FILE *fp = fopen("bigfile", "wb");
>Writing the appropriate number of bytes to fp should produce a file with the
>appropriate size...
>- if the OS can handle that size,
>- and the file system can too,

[...]

And if the OS doesn't happen to pad out binary files to
a full multiple of the sector size and use some kind of
mechanism (e.g., writing an end-of-file marker) to keep track
of how big the file is "really"

And if the OS doesn't happen to toss in some trailing NUL's on
the binary file.


This all relates strongly to the FAQ question asking how to find
out how big a file is, the answer to which is "You can't be sure
using standard C facilities, not even for binary files"
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      09-15-2007
Walter Roberson said:

<snip>

> This all relates strongly to the FAQ question asking how to find
> out how big a file is, the answer to which is "You can't be sure
> using standard C facilities, not even for binary files"


Right. This is precisely why I wrote "It's trivial, of course, to make
the attempt" rather than "It's trivial to solve this problem".

I note from followups that there were performance complaints about my
attempt.

<shrug width="gallic">
People ask if something is possible, and you show them how it might be,
and then they moan because it doesn't run in nothing flat with no
memory consumption, despite these constraints not being stated in the
original problem.

Well, people *will* be people, I guess.
</shrug>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      09-15-2007
Charlie Gordon wrote, On 15/09/07 13:32:
> "Wade Ward" <(E-Mail Removed)> a écrit dans le message de news:
> (E-Mail Removed)...
>> "Flash Gordon" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)-gordon.me.uk...
>>> Wade Ward wrote, On 15/09/07 11:13:
>>>> "Flash Gordon" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)-gordon.me.uk...
>>>>> It may, of course, be possible to create such a file using purely
>>>>> standard C by, for example, creating the file and writing that number
>>>>> of characters.
>>>> OP just dug up K&R2. I think this is easily within the realm of ISO C.
>>> I stated that it was potentially possible and even one way it could be
>>> done in ISO C so I don't see what you are getting at here, unless you
>>> were posting to agree with me.
>>>
>>> Depending on what is really wanted there may well be a better way to
>>> achieve it, such as using sparse files, but it all depends on the real
>>> requirements and the system in question. I certainly would not want to
>>> wait whilst such a file was written.

>> Yeah, well, I let Heathfield's program run for about fifteen minutes. I'm
>> missing something and my IQ isn't getting bigger tonight, so I'll let it
>> rest.
>>
>> The benchmark to beat is eight minutes. Sleep on it.
>>
>> unsigned long wait = 2282899UL;
>> fputs("please wait\n", stderr);
>> while(!errupt && wait--)
>> {
>> unsigned int erest = 1123;
>> while(!errupt && erest--)
>>
>> Tja.

>
> given todays average harware performance, 1 minute seems a good goal for
> this benchmark.
> using fwrite with a decent buffer size should do it.


Pick the right system and the right method and I would expect closer to
1s. Actually, I would expect a lot *less* than 1s. E.g.

markg@brenda:~$ rm /tmp/big
markg@brenda:~$ time ./a.out

real 0m0.002s
user 0m0.000s
sys 0m0.000s
markg@brenda:~$ ls -l /tmp/big
-rw-r--r-- 1 markg markg 2282899 2007-09-15 19:02 /tmp/big
markg@brenda:~$

For the earlier mentioned size of 2563695577 my method did not work, and
for various reasons (including portability) my method might not be
suitable to the OP. I did not use standard C to do this so the code is
not topical here.
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-15-2007
"Wade Ward" <(E-Mail Removed)> writes:
> How do I use the C Programming Language to create a files that is 2563695577
> bytes. The one line I think to know in this program is:
> long long m = 2563695577;
>
> EOF on my implementation is carriage return line feed (I think). I don't
> know if that is the 2563695578th byte or even the 2563695578th and the
> 2563695579th.
>
> The number in question is about two and a half billion. I can't remember
> what the minumum maximum is for this datatype, but I think I'm within an
> order of magnitude. Telling me to read the manual won't work, because I
> don't have a c compiler.


Why do you want to do this? Creating a file of an exact specified
size without saying anything about its contents seems like a very odd
requirement.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      09-15-2007
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>"Wade Ward" <(E-Mail Removed)> writes:
>> How do I use the C Programming Language to create a files that is 2563695577
>> bytes.


>Why do you want to do this? Creating a file of an exact specified
>size without saying anything about its contents seems like a very odd
>requirement.


>> Telling me to read the manual won't work, because I
>> don't have a c compiler.


Personally I find the latter an even odder requirement -- someone
wants to know a C program, but doesn't have a C compiler? And what
does having a C compiler have to do with reading C documentation,
a great deal of which is readily available through any decent
search engine?
--
Programming is what happens while you're busy making other plans.
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      09-15-2007
In article <(E-Mail Removed)-gordon.me.uk>,
Flash Gordon <(E-Mail Removed)> wrote:
>Charlie Gordon wrote, On 15/09/07 13:32:
>> "Wade Ward" <(E-Mail Removed)> a écrit dans le message de news:


>>> The benchmark to beat is eight minutes. Sleep on it.


>>> unsigned long wait = 2282899UL;
>>> fputs("please wait\n", stderr);
>>> while(!errupt && wait--)
>>> {
>>> unsigned int erest = 1123;
>>> while(!errupt && erest--)


>> given todays average harware performance, 1 minute seems a good goal for
>> this benchmark.


>Pick the right system and the right method and I would expect closer to
>1s. Actually, I would expect a lot *less* than 1s. E.g.


>for various reasons (including portability) my method might not be
>suitable to the OP. I did not use standard C to do this so the code is
>not topical here.


Heck, if you allow non-portability, you might not need to write any
code at all. For example, SGI IRIX provides "mkfile" to create a
file of any given size. If you really want C code, you could wrap
the call with system()

Then there are methods using a pair of fseek() (a pair because fseek
takes a signed long so you can't seek that far in one call) followed by
writing a byte, or go non-portable and just open the file and
ftruncate64() it to the size you want, or (non-portable again)
fseek64() followed by writing a byte. Or there's always the good old
unix utility "dd", no C code required...
--
Programming is what happens while you're busy making other plans.
 
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
Using exact-size structs to go thru raw byte buffers toe@lavabit.com C Programming 5 02-22-2008 11:04 PM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
New window - exact size... Domestos HTML 17 06-30-2005 04:39 PM
Specifying exact font point size bob HTML 4 06-18-2004 06:33 PM
OK you pedants - what is the *exact* size of a 35mm image? Alan F Cross Digital Photography 5 08-05-2003 10:47 PM



Advertisments