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

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.

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

mellyshum123@yahoo.ca wrote:Why don't you use fprintf?

--
Ian Collins.

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

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);

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

mellyshum123@yahoo.ca wrote: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);

--
Ian Collins.

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

mellyshum123@yahoo.ca wrote: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);

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

<mellyshum123@yahoo.cawrote in messageC 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.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

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

On Sat, 25 Nov 2006 09:13:28 -0000, "Malcolm"
<regniztar@btinternet.comwrote:
Except for the large number that deal with IBM mainframes, oriental
languages, the Cyrillic alphabet, Arabic, etc.
You probably meant fprintf, not fwrite.

Remove del for email

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

"Barry Schwarz" <schwarzb@doezl.netwrote in message
news:ujmhm257ea1lik70a1ceagc3c4uvb9ubg1@4ax.com...What characters do the Arabs use? Can you post some Arabic charcaters for us
to see?Yes, I manged to confuse myself.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

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

On Sun, 26 Nov 2006 10:25:21 -0000, "Malcolm"
<regniztar@btinternet.comwrote:
snip
Google for arabic alphabet or look at any picture of a protest in the
middle east.


Remove del for email

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

"Malcolm" <regniztar@btinternet.comwrote in message
news:iomdnZ2Ax5KvlPXYnZ2dnUVZ8qqdnZ2d@bt.com...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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking



--
Posted via a free Usenet account from http://www.teranews.com

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

2006-11-27 <456a5d9b$0$21132$88260bb3@free.teranews.com>,
Stephen Sprunk wrote:In C, there are only guaranteed to be hundreds, even as few as 128
non-ascii characters.

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

Random832 wrote: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.

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

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

On Mon, 27 Nov 2006 09:47:01 +0000, Richard Heathfield wrote:
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 :)

--
jay

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

jaysome said:

<snip>
ROTFL!
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

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

2006-11-27 <1164604145.980393.167750@45g2000cws.googlegroups. com>,
santosh wrote: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.

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

2006-11-27 <KNadncu4mtMgLvfYnZ2dnUVZ8qCdnZ2d@bt.com>,
Richard Heathfield wrote: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.

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

Random832 wrote:Not on all possible implementations. Mainframes and embedded systems
often have bigger char types.
Yes, but even the first 128 characters aren't guaranteed to be ASCII :)

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

Random832 wrote:And I suppose, vertical tab, backspace, carriage-return and form
feed...
They'll be represented in that manner all right, only encoded
differently, as naturally, the standard doesn't specify any encoding
scheme :)

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

Richard Heathfield wrote: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.

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

Tom St Denis said:
A great big box of bits.
So what you're saying is that you lack experience of non-ASCII systems. This
comes as no great surprise, but I don't see how it advances the argument in
either direction.
Since by your own admission you don't know what a mainframe is, I don't
quite see how you can make definitive statements about them.
I have no pitchfork. If you want one, I suggest you try eBay rather than
comp.lang.c.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

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

Richard Heathfield wrote:My post was a joke. Hence the P.S.

If your reply is supposed to be funny I don't get it.

Just makes me glad I'm not an old-timer fart who thinks everything was
better "in the old days." While I liked my 6809 and 8051 systems too
(and I'm no old timer) I think my Core 2 Duo is way more efficient
(watts/mips) and more productive. I think my modern GNU/Linux setup is
better than a 1983 copy of AT&T Unix, etc, etc, etc...

And btw, using a non-ASCII system isn't that special. I've used a few
EBIDIC [sp?] systems at IBM and frankly it's just a different encoding
(and converting/to/from is easy). I'd rather use ASCII out of
simplicity than other coding standards out of elitism.

So go out, grab a coffee, look up to the sky and get big heaping dosage
of PERSPECTIVE AND REALITY.

Tom

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

2006-11-27 <1164630096.031327.145570@14g2000cws.googlegroups. com>,
santosh wrote:But that's not guaranteed. Re-read for comprehension.
That wasn't the question, though.

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

2006-11-27 <1164630354.851818.233140@j72g2000cwa.googlegroups .com>,
santosh wrote:Those are ASCII, aren't they? I was referring to the fact that there is
a difference between "line feed" and "newline" that is ignored on most
modern systems, and ASCII contains only the former.
...."that particular manner" that I was referring to was ASCII encoding.
You're twisting words around.

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

Tom St Denis schrieb:<snip><snip>EBCDIC (Extended Binary Coded Decimal Interchange Code)

the BCD part implies, there might be more than just another Codepage
to convert to.

Wolfgang

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

Tom St Denis said:
Does that mean that, if it were *not* supposed to be funny, you *do* get it?
What is "in the old days" about non-ASCII systems? Do you think EBCDIC
systems have ceased to exist?
Nobody ever said it was. What *is* special is writing C code that won't
break just because you're running it on a non-ASCII system.
I'd rather write code once than twice.
My perspective is evidently different to yours, but that doesn't mean I
don't have one. As for reality, ignoring great big lumps of it won't make
those lumps cease to exist.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

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

Richard Heathfield wrote:If I ignore them hard enough, yes.
Well given that I write code that is routinely used on platforms I
don't even have access to... I'd think I'm not striving for
non-portable code here.
Um same here. I'm just really tired of hearing the "well on the
mainframes..." Newsflash, big deal. Embedded systems outweigh
mainframes a million to one in usage. It just irks me to read "the
big players ..." in context with mainframes.

Yes, write portable code. No, don't worship mainframe coders.

That said, the OP should just ASN1 encode their integer and avoid all
ambiguity :-)

Tom

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

Tom St Denis said:
So presumably you are not concerned about portability to such systems. Well,
that's fine, but some people are, and it is perfectly legitimate and proper
to discuss such matters in comp.lang.c, which deals with C, not with "C on
ASCII machines".
I'm not claiming that you are. But if your code relies on an ASCII
representation, then it /is/ non-portable to some extent, whether you are
striving for that outcome or not. That doesn't mean your code is no use. It
just means it isn't as portable as it could be.
They happen to be the best example of non-ASCII systems, that's all.
That's irrelevant to mainframe users, though.
Agreed.
Nobody is asking you to, or claiming that it's a good idea to do so. But
mainframe programmers have to be aware of such issues, and so do those who
claim to be writing portable code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

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

mellyshum123@yahoo.ca wrote:fwrite() allows you to specify the number of bytes to be written out,
so you could accomplish what you want through:

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

The second argument to fwrite is the size of a single element of buff
in bytes (to make it more generic, you could replace the hardcoded 1
with sizeof *buf). By definition, a single char has size 1.
strlen(buff) returns the number of characters in buff before the nul
terminator, which in this case is 3.

The result is that the characters '2', '5', and '6' are written to
outstream.

Of course, you could accomplish the exact same thing with far less pain
simply by writing

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

and bypass the buffer entirely, unless there's a specific reason you
need to use the buffer.
Strings in C are terminated by a 0, so the string "256" is the sequence
{'2', '5', 6', 0}. So you could write

int i = 0;
while (buff[i] != 0) // or just while(buf[i])
{
fputc(buff[i++], outstream);
}

Or you could just write

fputs(buff, outstream);

which will stop writing characters once it encounters the nul
terminator.
Why do you think you have to allocate space beforehand? Why not just
use the conversion operations offered by the *printf() family?

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

Richard Heathfield wrote:Wholeheartedly agree.

Before I get into my reply further, I want to apologize for upsetting
you. My original reply was just meant to be a joke. I wasn't trying
to suggest that "C is ASCII" or whatever. :-)
Exactly.

[for the benefit of others...] Internally I use tables to convert chars
to ASCII for my ASN1 code. The idea is simple, 'c' is 'c' on any
platform, the decimal representation of 'c' may change. But if you
have a table that has

{'c', 99},

You can easily convert 'c' to the ASCII value of 99 without violating
portability rules.
And many IBM systems (zLinux for instance) :-)
Perhaps. My experience with portable coding comes from the random
video game console and other embedded developers who picked up my code
and ran with it on random mixes of big/little endian, 32-bit/64-bit,
unaligned memory/aligned memory users.

Having your code which you only tested on a 32-bit little endian
unaligned memory x86 box run smoothly out of the box on a 64-bit
aligned big endian playstation [or HP-UX box] is fairly cool :-).

I guess in the context of code pages you're right. Mainframes are
likely the best source of violating the "all ASCII" world.

Tom

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

Random832 wrote:Yes, they're ASCII but just like the linefeed vs. newline ambiguity,
some of these other control characters may not have the same meaning,
and effect, from system to system. In that sense they're similar to the
linefeed character. The printable characters of ASCII don't suffer from
such system specific interpretations.