Writing an int to a file, not quite sure how buffers work.

[mellyshum123]

I'm wanting to write an int to a file, and so far I have written:

const char buff[20];
int num = 256 //for the sake of the example
sprintf(buff, "%d", num);

Now my question is what to do next. I could use fwrite, but I don't
understand how the size works, I'm not sure if it writes out the whole
buffer or not, and I definetly only want to write out "256."

I could use putc to go through the buffer and write out one character
at a time, but same issue, I don't know if that writes out the whole 20
character buffer or stops after the '256'.

I haven't had to use this stuff for a long time, and I completely
forget how this buffer stuff works and I'm finding it fairly annoying
to have to allot the space beforehand.

 

[Ian Collins]

I'm wanting to write an int to a file, and so far I have written:

const char buff[20];
int num = 256 //for the sake of the example
sprintf(buff, "%d", num);

Why don't you use fprintf?

 

[mellyshum123]

Why don't you use fprintf?

Ok. I still don't know how the buffer works. Does it print out the
entire buffer or just the int I have placed in it?

Supposing I wrote:

fprintf(outputfile, "%d",buff);

 

[Ian Collins]

Ok. I still don't know how the buffer works. Does it print out the
entire buffer or just the int I have placed in it?

Supposing I wrote:

fprintf(outputfile, "%d",buff);

Please keep enough context and trip signatures.

Given buff is a char[] (you wrote const char[], which you can't write
into), you get undefined behaviour.

If you had written

fprintf(outputfile, "%s", buff);

you would get the same in the file as you would get on you console had
you written

printf("%s", buff);

 

[J. J. Farrell]

Ok. I still don't know how the buffer works. Does it print out the
entire buffer or just the int I have placed in it?

Supposing I wrote:

fprintf(outputfile, "%d",buff);

If I remember your previous posting correctly, buff wasn't an int so
that wouldn't work.

The question is: why do you want to use a buffer at all? What's wrong
with

fprintf(outputfile, "%d", num);

 

[Malcolm]

Ok. I still don't know how the buffer works. Does it print out the
entire buffer or just the int I have placed in it?

Supposing I wrote:

fprintf(outputfile, "%d",buff);

C files come in binary or text flavours.
To write an integer to a binary file

fwrite(&x, sizeof(int), 1, fp);

This will write the bit pattern of the int to the file.

To do it in a machine-independent way

fputc( (x >> 8) & 0xFF, fp);
fputc( x & 0xFF, fp);

This will write a 16-bit big-endian integer to the file. Obviously you might
want to rewrite to make integers little-endian, or 32 bits.

Text files only understnad characters, almost always ASCII. So you have to
write the string "1234" to represent the integer 1234.
However fwrite(fp, "%d", x)) will do the conversion for you.

if you prefer you can write
char buff[64];
sprintf(buff, "%d", x);

fprintf(fp, "%s", buff);

using fprintf to write as a string.

Or you could use fwrite

fwrite(buff, 1, strlen(buff), fp);

There is not normally much point in doing this, unless you want your own
integer-to string conversion routine, for instance to write in binary rather
than decimal.

 

[Barry Schwarz]

C files come in binary or text flavours.
To write an integer to a binary file

fwrite(&x, sizeof(int), 1, fp);

This will write the bit pattern of the int to the file.

To do it in a machine-independent way

fputc( (x >> 8) & 0xFF, fp);
fputc( x & 0xFF, fp);

This will write a 16-bit big-endian integer to the file. Obviously you might
want to rewrite to make integers little-endian, or 32 bits.

Text files only understnad characters, almost always ASCII. So you have to

Except for the large number that deal with IBM mainframes, oriental
languages, the Cyrillic alphabet, Arabic, etc.

write the string "1234" to represent the integer 1234.
However fwrite(fp, "%d", x)) will do the conversion for you.

You probably meant fprintf, not fwrite.

if you prefer you can write
char buff[64];
sprintf(buff, "%d", x);

fprintf(fp, "%s", buff);

using fprintf to write as a string.

Or you could use fwrite

fwrite(buff, 1, strlen(buff), fp);

There is not normally much point in doing this, unless you want your own
integer-to string conversion routine, for instance to write in binary rather
than decimal.

Remove del for email

 

[Malcolm]

Except for the large number that deal with IBM mainframes, oriental
languages, the Cyrillic alphabet, Arabic, etc.

What characters do the Arabs use? Can you post some Arabic charcaters for us
to see?

You probably meant fprintf, not fwrite.

Yes, I manged to confuse myself.

 

[Barry Schwarz]

snip

What characters do the Arabs use? Can you post some Arabic charcaters for us
to see?

Google for arabic alphabet or look at any picture of a protest in the
middle east.


Remove del for email

 

[Stephen Sprunk]

Text files only understnad characters, almost always ASCII.

Text files are full of "characters", yes, but that doesn't limit things
to ASCII; there are thousands of non-ASCII characters. There are a
variety of encodings that allow either subsets or the full range of
Unicode characters to be stored in a text file, with varying efficiency.
Of course, one needs to know what encoding a particular file uses, but
that's an entirely different problem.

"Almost always ASCII" assumes a particular context; in the US it may be
true, but outside the US virtually all files will be in some other
encoding to handle the non-ASCII characters in virtually all other
languages.

S

 

[Random832]

Text files are full of "characters", yes, but that doesn't limit things
to ASCII; there are thousands of non-ASCII characters.

In C, there are only guaranteed to be hundreds, even as few as 128
non-ascii characters.

 

[santosh]

In C, there are only guaranteed to be hundreds, even as few as 128
non-ascii characters.

No. In C only the characters in the source and execution character sets
as given in the standard are guaranteed to be present.

And text files are not restricted, or in any way connected, to C.

 

[Richard Heathfield]

Random832 said:

In C, there are only guaranteed to be hundreds, even as few as 128
non-ascii characters.

True. On the other hand, C doesn't guarantee that there will be *any* ASCII
characters.

 

[jaysome]

Random832 said:


True. On the other hand, C doesn't guarantee that there will be *any* ASCII
characters.

True. On the other hand, C's guarantee isn't worth much. ASCII is the
de facto standard for encoding in C. Just ask all those people who submit
their C source code wrapped up in those *.zip and *.gz and *.tgz and *.tar
and *.tarball or TARBALL or whatever files

 

[Richard Heathfield]

jaysome said:

ASCII is the de facto standard for encoding in C.
ROTFL!

Just ask all those people who submit
their C source code wrapped up in those *.zip and *.gz and *.tgz and *.tar
and *.tarball or TARBALL or whatever files

Now go and ask the big players (or rather their sysops) how many of their
mainframe C programs (of which there are a very great many) are stored in
ASCII. You're likely to get a number that is very close, or equal, to 0.

 

[Random832]

No. In C only the characters in the source and execution character sets
as given in the standard are guaranteed to be present.

My point was that the range of the character type is only guaranteed to
have 256 (signed character is only guaranteed to have 255, so I was
slightly mistaken) values. Since ASCII has only 128 characters, at least
the other 128 of those 256 values are guaranteed to be non-ASCII.

 

[Random832]

Random832 said:


True. On the other hand, C doesn't guarantee that there will be *any* ASCII
characters.

Well, the 101 characters it does guarantee are all present in ASCII
(except, arguably, newline). It'sj ust that they're not guaranteed to be
represented in that particular manner.

 

[santosh]

My point was that the range of the character type is only guaranteed to
have 256 (signed character is only guaranteed to have 255, so I was
slightly mistaken) values.

Not on all possible implementations. Mainframes and embedded systems
often have bigger char types.

Since ASCII has only 128 characters, at least
the other 128 of those 256 values are guaranteed to be non-ASCII.

Yes, but even the first 128 characters aren't guaranteed to be ASCII

 

[santosh]

Well, the 101 characters it does guarantee are all present in ASCII
(except, arguably, newline).

And I suppose, vertical tab, backspace, carriage-return and form
feed...

It'sj ust that they're not guaranteed to be
represented in that particular manner.

They'll be represented in that manner all right, only encoded
differently, as naturally, the standard doesn't specify any encoding
scheme

 

[Tom St Denis]

Now go and ask the big players (or rather their sysops) how many of their
mainframe C programs (of which there are a very great many) are stored in
ASCII. You're likely to get a number that is very close, or equal, to 0.

What the hell is a mainframe?

I used to play with HPCs while working at AMD and frankly you're an old
timer. They pretty much all run GNU/Linux (or some derivative) and the
default code page is the ASCII (whatever the ANSI equiv is).

And nowadays we call them "clusters" not mainframes.



Tom

P.S. mostly just messing with you, so put down the pitchfork and step
aside.