473,322 Members | 1,501 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

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.

Nov 24 '06 #1
30 1960
me**********@yahoo.ca wrote:
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?

--
Ian Collins.
Nov 24 '06 #2

Why don't you use fprintf?

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

Nov 24 '06 #3
me**********@yahoo.ca wrote:
>
>>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);
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.
Nov 24 '06 #4

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

Nov 24 '06 #5
<me**********@yahoo.cawrote in message
>Why don't you use fprintf?

--
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);
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.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Nov 25 '06 #6
On Sat, 25 Nov 2006 09:13:28 -0000, "Malcolm"
<re*******@btinternet.comwrote:
><me**********@yahoo.cawrote in message
>>Why don't you use fprintf?

--
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);
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
Nov 26 '06 #7
"Barry Schwarz" <sc******@doezl.netwrote in message
news:uj********************************@4ax.com...
On Sat, 25 Nov 2006 09:13:28 -0000, "Malcolm"
<re*******@btinternet.comwrote:
>><me**********@yahoo.cawrote in message
>>>Why don't you use fprintf?

--
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);
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.
What characters do the Arabs use? Can you post some Arabic charcaters for us
to see?
>
>>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.
Yes, I manged to confuse myself.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Nov 26 '06 #8
On Sun, 26 Nov 2006 10:25:21 -0000, "Malcolm"
<re*******@btinternet.comwrote:
>"Barry Schwarz" <sc******@doezl.netwrote in message
news:uj********************************@4ax.com.. .
>On Sat, 25 Nov 2006 09:13:28 -0000, "Malcolm"
<re*******@btinternet.comwrote:
snip
>>>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.
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
Nov 26 '06 #9
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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

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

Nov 27 '06 #10
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
>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.
In C, there are only guaranteed to be hundreds, even as few as 128
non-ascii characters.
Nov 27 '06 #11
Random832 wrote:
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.

Nov 27 '06 #12
Random832 said:
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
>"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
>>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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Nov 27 '06 #13
On Mon, 27 Nov 2006 09:47:01 +0000, Richard Heathfield wrote:
Random832 said:
>2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
>>"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com.. .
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.

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

Nov 27 '06 #14
jaysome said:

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Nov 27 '06 #15
2006-11-27 <11**********************@45g2000cws.googlegroups. com>,
santosh wrote:
Random832 wrote:
>2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.
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.
And text files are not restricted, or in any way connected, to C.
Nov 27 '06 #16
2006-11-27 <KN******************************@bt.com>,
Richard Heathfield wrote:
Random832 said:
>2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
>>"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com.. .
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.

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.
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.
Nov 27 '06 #17
Random832 wrote:
2006-11-27 <11**********************@45g2000cws.googlegroups. com>,
santosh wrote:
Random832 wrote:
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.

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

Nov 27 '06 #18
Random832 wrote:
2006-11-27 <KN******************************@bt.com>,
Richard Heathfield wrote:
Random832 said:
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.

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

Nov 27 '06 #19
Richard Heathfield wrote:
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.

Nov 27 '06 #20
Tom St Denis said:
Richard Heathfield wrote:
>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? :-)
A great big box of bits.
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).
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.
And nowadays we call them "clusters" not mainframes.
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.
:-)

Tom

P.S. mostly just messing with you, so put down the pitchfork and step
aside.
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.
Nov 27 '06 #21
Richard Heathfield wrote:
P.S. mostly just messing with you, so put down the pitchfork and step
aside.

I have no pitchfork. If you want one, I suggest you try eBay rather than
comp.lang.c.
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

Nov 27 '06 #22
2006-11-27 <11**********************@14g2000cws.googlegroups. com>,
santosh wrote:
Random832 wrote:
>2006-11-27 <11**********************@45g2000cws.googlegroups. com>,
santosh wrote:
Random832 wrote:
2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.

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.
But that's not guaranteed. Re-read for comprehension.
>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 :)
That wasn't the question, though.
Nov 27 '06 #23
2006-11-27 <11**********************@j72g2000cwa.googlegroups .com>,
santosh wrote:
Random832 wrote:
>2006-11-27 <KN******************************@bt.com>,
Richard Heathfield wrote:
Random832 said:

2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com.. .
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.

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.

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...
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.
>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 :)
...."that particular manner" that I was referring to was ASCII encoding.
You're twisting words around.
Nov 27 '06 #24
Tom St Denis schrieb:
Richard Heathfield wrote:
<snip>
EBIDIC [sp?] systems at IBM and frankly it's just a different encoding
<snip>
Tom
EBCDIC (Extended Binary Coded Decimal Interchange Code)

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

Wolfgang
Nov 27 '06 #25
Tom St Denis said:
Richard Heathfield wrote:
P.S. mostly just messing with you, so put down the pitchfork and step
aside.

I have no pitchfork. If you want one, I suggest you try eBay rather than
comp.lang.c.

My post was a joke. Hence the P.S.

If your reply is supposed to be funny I don't get it.
Does that mean that, if it were *not* supposed to be funny, you *do* get it?
Just makes me glad I'm not an old-timer fart who thinks everything was
better "in the old days."
What is "in the old days" about non-ASCII systems? Do you think EBCDIC
systems have ceased to exist?
And btw, using a non-ASCII system isn't that special.
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'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.
I'd rather write code once than twice.
So go out, grab a coffee, look up to the sky and get big heaping dosage
of PERSPECTIVE AND REALITY.
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.
Nov 27 '06 #26
Richard Heathfield wrote:
Just makes me glad I'm not an old-timer fart who thinks everything was
better "in the old days."

What is "in the old days" about non-ASCII systems? Do you think EBCDIC
systems have ceased to exist?
If I ignore them hard enough, yes.
And btw, using a non-ASCII system isn't that special.

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.
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.
I'd rather write code once than twice.
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

Nov 27 '06 #27
Tom St Denis said:
Richard Heathfield wrote:
Just makes me glad I'm not an old-timer fart who thinks everything was
better "in the old days."

What is "in the old days" about non-ASCII systems? Do you think EBCDIC
systems have ceased to exist?

If I ignore them hard enough, yes.
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".
And btw, using a non-ASCII system isn't that special.

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.

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.
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.
>
>I'd rather write code once than twice.

Um same here. I'm just really tired of hearing the "well on the
mainframes..."
They happen to be the best example of non-ASCII systems, that's all.
Newsflash, big deal. Embedded systems outweigh
mainframes a million to one in usage.
That's irrelevant to mainframe users, though.
It just irks me to read "the
big players ..." in context with mainframes.

Yes, write portable code.
Agreed.
No, don't worship mainframe coders.
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.
Nov 27 '06 #28

me**********@yahoo.ca wrote:
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."
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.
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'.
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.
>
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.
Why do you think you have to allocate space beforehand? Why not just
use the conversion operations offered by the *printf() family?

Nov 27 '06 #29
Richard Heathfield wrote:
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".
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. :-)
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.

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.
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.
Um same here. I'm just really tired of hearing the "well on the
mainframes..."

They happen to be the best example of non-ASCII systems, that's all.
And many IBM systems (zLinux for instance) :-)
No, don't worship mainframe coders.

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

Nov 27 '06 #30
Random832 wrote:
2006-11-27 <11**********************@j72g2000cwa.googlegroups .com>,
santosh wrote:
Random832 wrote:
2006-11-27 <KN******************************@bt.com>,
Richard Heathfield wrote:
Random832 said:

2006-11-27 <45***********************@free.teranews.com>,
Stephen Sprunk wrote:
"Malcolm" <re*******@btinternet.comwrote in message
news:io******************************@bt.com...
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.

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.

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

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

Nov 27 '06 #31

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Ben Jeurissen | last post by:
Hello, I have to deal with the following issue in C++: Two threads are started from the main thread, both capturing images from a different firewire camera. Both threads take shots of 460800...
3
by: Mario | last post by:
Hello, I couldn't find a solution to the following problem (tried google and dejanews), maybe I'm using the wrong keywords? Is there a way to open a file (a linux fifo pipe actually) in...
385
by: Xah Lee | last post by:
Jargons of Info Tech industry (A Love of Jargons) Xah Lee, 2002 Feb People in the computing field like to spur the use of spurious jargons. The less educated they are, the more they like...
19
by: Johnny Google | last post by:
Here is an example of the type of data from a file I will have: Apple,4322,3435,4653,6543,4652 Banana,6934,5423,6753,6531 Carrot,3454,4534,3434,1111,9120,5453 Cheese,4411,5522,6622,6641 The...
16
by: Claudio Grondi | last post by:
I have a 250 Gbyte file (occupies the whole hard drive space) and want to change only eight bytes in this file at a given offset of appr. 200 Gbyte (all other data in that file should remain...
3
by: John Smith | last post by:
I try to write some data to a file. After some data had supposedly been written to the file, I opened the file before the program closed it and found it empty. What's wrong with my code? Thanks. ...
6
by: paul.anderson | last post by:
This code doesn't work - the first retrieval of t2 returns valid data, the subsequent do not. Please help!!! int main(int argc, char* argc){ struct Test{ int i; int j; intk; int l; }
3
by: Barry Flynn | last post by:
Hi I am working with a VB 2005 program which has been converted from VB6. It writes data out to a flat file, with code like the following line WriteLine(riFileNo, "Hist", lsAssetID,...
11
by: Krzysztof Retel | last post by:
Hi guys, I am struggling writing fast UDP server. It has to handle around 10000 UDP packets per second. I started building that with non blocking socket and threads. Unfortunately my approach...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.