Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63008 > unrolled thread
| Started by | bilsch01 <king621@comcast.net> |
|---|---|
| First post | 2015-06-06 04:58 -0700 |
| Last post | 2015-07-26 01:00 +0200 |
| Articles | 20 on this page of 112 — 19 participants |
Back to article view | Back to comp.lang.c
counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 04:58 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:05 +0100
Re: counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 05:24 -0700
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-06 05:41 -0700
Re: counting bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-06 14:00 +0100
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:52 +0100
Re: counting bytes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-06 10:27 -0400
Re: counting bytes jt@toerring.de (Jens Thoms Toerring) - 2015-06-06 22:31 +0000
THANKS EVERYBODY FOR THE INFO bilsch01 <king621@comcast.net> - 2015-06-06 23:35 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 10:08 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-07 09:22 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 18:07 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-08 04:03 -0700
Re: THANKS EVERYBODY FOR THE INFO Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:12 -0700
Re: THANKS EVERYBODY FOR THE INFO Keith Thompson <kst-u@mib.org> - 2015-06-07 08:01 -0700
Re: counting bytes gordonb.3gcai@burditt.org (Gordon Burditt) - 2015-06-07 05:02 -0500
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 15:32 +0200
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 12:48 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:05 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 22:17 +0100
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:49 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 23:37 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:25 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:21 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-11 13:54 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:33 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-20 09:51 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:49 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 12:26 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:16 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-30 23:15 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:07 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 14:31 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 05:31 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 17:09 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-05 19:29 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:38 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-06 17:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:50 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-09-06 22:00 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:24 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-24 20:03 -0400
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 22:13 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 02:22 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 11:39 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 09:48 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 14:04 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:22 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 11:07 -0400
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 12:43 -0400
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 13:32 -0400
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 20:14 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 17:24 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 23:02 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 19:17 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 16:37 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 06:10 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-26 08:31 -0400
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 21:32 +0100
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 13:25 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 11:31 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 11:30 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 14:29 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 12:14 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:39 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:32 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-08-01 16:41 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-08-01 20:23 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:01 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 19:42 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:16 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 22:04 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:10 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:10 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 22:16 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:52 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 08:51 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:19 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 09:39 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-08-01 13:06 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 20:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:52 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 15:14 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 07:54 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 10:48 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-11 17:50 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:36 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-20 15:14 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:38 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:12 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:18 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:03 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:15 +0000
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:46 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:33 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:48 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-20 11:18 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-24 11:14 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:02 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-30 13:10 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-01 10:53 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 14:46 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-08 09:05 +0200
Re: counting bytes Siri Cruz <chine.bleu@yahoo.com> - 2015-06-06 05:06 -0700
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 00:58 +0200
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 01:00 +0200
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | bilsch01 <king621@comcast.net> |
|---|---|
| Date | 2015-06-06 04:58 -0700 |
| Subject | counting bytes |
| Message-ID | <mkun7o$pc2$1@dont-email.me> |
The code below writes a file to disk that has 52 bytes. There are 4
float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
When I change %i to %u the total is 56 bytes. I think it should be the
same whether %i or %u.
int main(){
int xf=65535, yf=0, xof=65535, yof=0, xm=65535, ym=0, delay=0,
glength=65535;
float w1=0.5, w2=2.0, w3=0.14159, k1=.01;
FILE *fp;
fp = fopen("gdata", "w");
fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
fclose(fp);
}
[toc] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-06 13:05 +0100 |
| Message-ID | <mkunkk$r2n$1@dont-email.me> |
| In reply to | #63008 |
On 06/06/2015 12:58, bilsch01 wrote:
> The code below writes a file to disk that has 52 bytes. There are 4
> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
Isn't int usually 4 bytes too?
But anyway, those are the binary sizes. You're writing out these values
as text. It's completely different. That 65535 2-byte int value will
take 5 bytes as text: "65535", while a 2-byte zero will take 1 byte or 1
character: "0".
You need to decide on your file format, packed binary or human-readable
text, first.
> fp = fopen("gdata", "w");
> fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | bilsch01 <king621@comcast.net> |
|---|---|
| Date | 2015-06-06 05:24 -0700 |
| Message-ID | <mkuon6$vf9$1@dont-email.me> |
| In reply to | #63009 |
On 06/06/2015 05:05 AM, Bartc wrote:
> On 06/06/2015 12:58, bilsch01 wrote:
>> The code below writes a file to disk that has 52 bytes. There are 4
>> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
>
> Isn't int usually 4 bytes too?
>
> But anyway, those are the binary sizes. You're writing out these values
> as text. It's completely different. That 65535 2-byte int value will
> take 5 bytes as text: "65535", while a 2-byte zero will take 1 byte or 1
> character: "0".
>
> You need to decide on your file format, packed binary or human-readable
> text, first.
>
>> fp = fopen("gdata", "w");
>> fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
>>
>
I didn't know %i and %f meant to save them as text. OK. How do I save
them as packed binary. I read that the 'b' in "rb" and "wb" only
counted in Windows. I'm using Ubuntu.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-06 05:41 -0700 |
| Message-ID | <dd4ccdb8-8803-4acf-934a-0beb6d05cf36@googlegroups.com> |
| In reply to | #63011 |
On Saturday, June 6, 2015 at 1:24:23 PM UTC+1, bilsch01 wrote:
>
> I didn't know %i and %f meant to save them as text. OK. How do I save
> them as packed binary. I read that the 'b' in "rb" and "wb" only
> counted in Windows. I'm using Ubuntu.
To save something in binary
int anint = 42;
float afloat = 1.618;
FILE *fp = fopen("savedfile.bin", "wb");
if!fp)
/* error handling code, can't create file */
fwrite(&afloat, sizeof(float), 1, fp);
fwrite(&anint, sizeof(int), 1, fp);
if(ferror(fp))
/* write error */
err = fclose(fp);
if(err == EOF)
/* write error, can't flush file to disk for some reason */
To retrive it
FILE *fp = fopen("savedfile.bin", "rb");
if(!fp)
/* err handlign code, can't create file */
N = fread(&afloat, sizeof(float), 1, fp);
if(N != 1)
/* read error */
N = fread(&anint, sizeof(int), 1, fp);
if(N != 1)
/* read error */
fclose(fp);
However generally it's best to save in a consistent binary format, not
rely on the machine representation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-06 14:00 +0100 |
| Message-ID | <87h9qlm1ob.fsf@bsb.me.uk> |
| In reply to | #63012 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > To save something in binary <snip> > fwrite(&afloat, sizeof(float), 1, fp); > fwrite(&anint, sizeof(int), 1, fp); The pattern fwrite(&afloat, sizeof afloat, 1, fp); fwrite(&anint, sizeof anint, 1, fp); is usually better. It's checkable without reference to the variable's declaration and can even be made into a macro #define write_var(v, f) fwrite(&v, sizeof v, 1, f) if that sort of thing is the sort of thing you like. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-06 13:52 +0100 |
| Message-ID | <mkuqd0$6h8$1@dont-email.me> |
| In reply to | #63011 |
On 06/06/2015 13:24, bilsch01 wrote:
> On 06/06/2015 05:05 AM, Bartc wrote:
>> On 06/06/2015 12:58, bilsch01 wrote:
>>> The code below writes a file to disk that has 52 bytes. There are 4
>>> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
>>
>> Isn't int usually 4 bytes too?
>>
>> But anyway, those are the binary sizes. You're writing out these values
>> as text. It's completely different. That 65535 2-byte int value will
>> take 5 bytes as text: "65535", while a 2-byte zero will take 1 byte or 1
>> character: "0".
>>
>> You need to decide on your file format, packed binary or human-readable
>> text, first.
>>
>>> fp = fopen("gdata", "w");
>>> fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
>>>
>>>
>>
>
> I didn't know %i and %f meant to save them as text. OK. How do I save
> them as packed binary. I read that the 'b' in "rb" and "wb" only
> counted in Windows. I'm using Ubuntu.
That "b" 'binary' format is to do with newlines being converted between
CRLF and LF forms as files are read or written.
In Ubuntu it doesn't make any difference as newlines are always LF. But
you still have text files and binary files.
1234 written as text, gives a file containing these hex bytes:
31 32 33 34
(0x31 is ASCII for '1')
1234, written as a 16-bit binary value to a file, will give a file
containing these hex bytes:
D2 04
(0x4D2 is 1234) This example uses 'little-endian' format, something else
to consider.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-06-06 10:27 -0400 |
| Message-ID | <YqDcx.12392$OH7.4462@fx28.iad> |
| In reply to | #63011 |
On Saturday June 6 2015 08:24, in comp.lang.c, "bilsch01"
<king621@comcast.net> wrote:
> On 06/06/2015 05:05 AM, Bartc wrote:
>> On 06/06/2015 12:58, bilsch01 wrote:
>>> The code below writes a file to disk that has 52 bytes. There are 4
>>> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
>>
>> Isn't int usually 4 bytes too?
>>
>> But anyway, those are the binary sizes. You're writing out these values
>> as text. It's completely different. That 65535 2-byte int value will
>> take 5 bytes as text: "65535", while a 2-byte zero will take 1 byte or 1
>> character: "0".
>>
>> You need to decide on your file format, packed binary or human-readable
>> text, first.
>>
>>> fp = fopen("gdata", "w");
>>>
fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
>>>
>>
>
> I didn't know %i and %f meant to save them as text. OK. How do I save
> them as packed binary.
One way would be to store your data in a structure, and read/write the
structure to file
As in (off the top of my head/uncompiled/untested):
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
struct
{
int xf,
yf,
xof,
yof,
xm,
ym,
delay,
glength;
float w1,
w2,
w3,
k1;
} gdata = {65535,
0,
65535,
0,
65535,
0,
0,
65535,
0.5,
2.0,
0.14159,
0.01};
FILE *fp;
if ((fp = fopen("gdata", "wb")) != NULL)
{
fwrite(&gdata,sizeof(gdata),1,fp);
fclose(fp);
}
else return EXIT_FAILURE;
return EXIT_SUCCESS;
}
> I read that the 'b' in "rb" and "wb" only
> counted in Windows. I'm using Ubuntu.
Open the file as "rb" or "wb"; in Linux, it doesn't make a difference, but on
other platforms it will. You /may/ have need to transport your data file to a
different platform one day.
HTH
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2015-06-06 22:31 +0000 |
| Message-ID | <cthalvFnjb7U1@mid.uni-berlin.de> |
| In reply to | #63015 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Saturday June 6 2015 08:24, in comp.lang.c, "bilsch01"
> <king621@comcast.net> wrote:
> > On 06/06/2015 05:05 AM, Bartc wrote:
> >> On 06/06/2015 12:58, bilsch01 wrote:
> >>> The code below writes a file to disk that has 52 bytes. There are 4
> >>> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
> >>
> >> Isn't int usually 4 bytes too?
> >>
> >> But anyway, those are the binary sizes. You're writing out these values
> >> as text. It's completely different. That 65535 2-byte int value will
> >> take 5 bytes as text: "65535", while a 2-byte zero will take 1 byte or 1
> >> character: "0".
> >>
> >> You need to decide on your file format, packed binary or human-readable
> >> text, first.
> >>
> >>> fp = fopen("gdata", "w");
> >>>
> fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
> >>>
> >>
> >
> > I didn't know %i and %f meant to save them as text. OK. How do I save
> > them as packed binary.
> One way would be to store your data in a structure, and read/write the
> structure to file
> As in (off the top of my head/uncompiled/untested):
> #include <stdio.h>
> #include <stdlib.h>
> int main(void)
> {
> struct
> {
> int xf,
> yf,
> xof,
> yof,
> xm,
> ym,
> delay,
> glength;
> float w1,
> w2,
> w3,
> k1;
> } gdata = {65535,
> 0,
> 65535,
> 0,
> 65535,
> 0,
> 0,
> 65535,
> 0.5,
> 2.0,
> 0.14159,
> 0.01};
> FILE *fp;
> if ((fp = fopen("gdata", "wb")) != NULL)
> {
> fwrite(&gdata,sizeof(gdata),1,fp);
> fclose(fp);
> }
> else return EXIT_FAILURE;
> return EXIT_SUCCESS;
> }
> > I read that the 'b' in "rb" and "wb" only
> > counted in Windows. I'm using Ubuntu.
> Open the file as "rb" or "wb"; in Linux, it doesn't make a difference, but on
> other platforms it will. You /may/ have need to transport your data file to a
> different platform one day.
If you do so please be aware that this DOES NOT store the date in
a format that you're guaranteed to be able to read in on a dif-
ferent computer. If you e.g. write them out on a 32-bit machine,
transfer the resulting file to a 64-bit machine (even when run-
ning the exact same operating system) and try to read the file
in you could be in for a surprise. The number of bytes of a e.g.
an int are not something that's the same on all computers. And
neither is the way binary data are stored.
So already your assumption that an "int" is always 4 bytes is
wrong. It may be 2 bytes, 4 bytes or even more - it depends on
the CPU. And neither is it a given that the data stored for an
int start with the least or the most siginificant byte. So, un-
less you know very well what you're doing refrain from trying
to store data in binary a format. If you do you must understand
what differences exist and how to deal with the resulting issues.
Otherwise you may end up with data files that you can read in on
one type of machine but not on a different one.
I'm a bit sensitive on this point because, some years back, I
was bitten by exactly these issues rather badly. I had written
a program that my collegues liked and started to use. Being
young and naive (or incompetent, to be truthful) I had fi-
gured that writing out structures in binary would be a nice
thing, resulting in shorter data files and making reading the
data back in so much simpler (just a single line of fread()
instead of lots of code to parse ASCII data). But then we got
a different machine (long-endian 64-bits instead of the lit-
tle-endian 32-bit machines I was used to) and none of the
files, which were the result of quite a bit of work, could
be read in on the new machine. A bit of red-face time for me
- but it made me learn and, hopefully, become a bit less in-
competent;-)
So, before you decide to store data in binary form make sure
that you understand that there are different binary repre-
sentations for even the most common types in C:
* with fwrite() you "dump" memory contents, exactly as they
are, into a file - with no "translation" at all - and
fread() does exactly the reverse, i.e., it pull data from
a file and writes them into memory with no modifications,
* the size of even an int is not necessarily the same on dif-
ferent machines,
* some machines store the less important bytes first, others
do it the other way round (and, if something has more than
2 bytes, the number of theoretically possible ways to store
them grows with the factorial of the number of bytes),
* structures have the additinal draw-back that there can be
padding between the members of the structure, which can not
only be different from machine to machine, but also, in prin-
ciple, from compiler to compiler - or even change between
compiler versions.
If you want to store data in a binary format then you have to
either store also information about the binary representation
on the machine that wrote the data (and, for reading them back
in, functions that can extract them according to that informa-
tion) or make sure that they always get written in a common
format that can be interpreted on all machines that may have
to read them in. Or use ASCII. Or use some serialization li-
brary that does all the ugly, low-level work for you.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | bilsch01 <king621@comcast.net> |
|---|---|
| Date | 2015-06-06 23:35 -0700 |
| Subject | THANKS EVERYBODY FOR THE INFO |
| Message-ID | <ml0olt$n8j$1@dont-email.me> |
| In reply to | #63031 |
> So, I'll save and retrieve the data via fprintf and fscanf, and forget about the exact number of bytes. The computers will keep track of that part - right?. Ultimately there will be about 100 of these 12-item vectors (each having 4 float and 8 int) that I will have in the same file as the program that uses them. But for the job of selecting the particular vectors I will save them in a file one at a time using fprintf. Thanks. Bill S.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-07 10:08 +0100 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <871thnlwbw.fsf@bsb.me.uk> |
| In reply to | #63034 |
bilsch01 <king621@comcast.net> writes: > So, I'll save and retrieve the data via fprintf and fscanf, and forget > about the exact number of bytes. The computers will keep track of > that part - right?. Ultimately there will be about 100 of these > 12-item vectors (each having 4 float and 8 int) that I will have in > the same file as the program that uses them. But for the job of > selecting the particular vectors I will save them in a file one at a > time using fprintf. Yes, that's not a lot of data and there is very little advantage (and some disadvantages) to saving it as a binary bit-image. However, for some applications, it's important that the number read back is exactly the number written saved, and for floating point numbers that's often a bit fiddly to do using decimal (%f). Modern C has the %a format that prints a floating point number using hex so that when the internal format is binary (as it almost always is) you will get back exactly the number you wrote. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-07 09:22 -0700 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <5b8202f5-33d1-4fe7-8adb-c96ef91a89ea@googlegroups.com> |
| In reply to | #63035 |
On Sunday, June 7, 2015 at 10:08:46 AM UTC+1, Ben Bacarisse wrote: > > However, for some applications, it's important that the number read back > is exactly the number written saved, and for floating point numbers > that's often a bit fiddly to do using decimal (%f). > Not really. You have to know the trick, which is double f_savemeexactly = acos(0.0) *2; /* number we want to preserve to machine precison */ fprintf(fp, "%.*g\n", DBL_DIG, f_savemexactly); Then you can read it in with fscanf() or strtod(). If everything works as specified, you should get an exact result back.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-07 18:07 +0100 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <87eglnjvkh.fsf@bsb.me.uk> |
| In reply to | #63040 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, June 7, 2015 at 10:08:46 AM UTC+1, Ben Bacarisse wrote: >> >> However, for some applications, it's important that the number read >> back is exactly the number written [...], and for floating point >> numbers that's often a bit fiddly to do using decimal (%f). >> > Not really. You have to know the trick, which is > > double f_savemeexactly = acos(0.0) *2; /* number we want to preserve to > machine precison */ > fprintf(fp, "%.*g\n", DBL_DIG, f_savemexactly); > > Then you can read it in with fscanf() or strtod(). If everything works > as specified, you should get an exact result back. No, that does not work. It's close, but that's my point -- it's fiddly to get right. Using %a (where available) is easier. Don't get me wrong -- like all programming, once you work it out it's easy. The point is that it won't be obvious to someone learning C why your code does not save the number exactly. That's all I mean by "a bit fiddly". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-08 04:03 -0700 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <1329fe07-bded-424b-9b3a-972932559dc9@googlegroups.com> |
| In reply to | #63042 |
On Sunday, June 7, 2015 at 6:08:08 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Sunday, June 7, 2015 at 10:08:46 AM UTC+1, Ben Bacarisse wrote: > >> > >> However, for some applications, it's important that the number read > >> back is exactly the number written [...], and for floating point > >> numbers that's often a bit fiddly to do using decimal (%f). > >> > > Not really. You have to know the trick, which is > > > > double f_savemeexactly = acos(0.0) *2; /* number we want to preserve to > > machine precison */ > > fprintf(fp, "%.*g\n", DBL_DIG, f_savemexactly); > > > > Then you can read it in with fscanf() or strtod(). If everything works > > as specified, you should get an exact result back. > > No, that does not work. It's close, but that's my point -- it's fiddly > to get right. Using %a (where available) is easier. > > Don't get me wrong -- like all programming, once you work it out it's > easy. The point is that it won't be obvious to someone learning C why > your code does not save the number exactly. That's all I mean by "a bit > fiddly". > You're right. DBL_DIG is the number of digits guaranteed to be correct, not the number needed to represent the value exactly. Never noticed that before. In fact you almost never want to save a double exactly to a text file - if the program falls over because you drop a bit of a real in a text format file, it's almost certainly very poorly written.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:12 -0700 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <kfn8uamzq1a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63040 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, June 7, 2015 at 10:08:46 AM UTC+1, Ben Bacarisse wrote: > >> However, for some applications, it's important that the number read back >> is exactly the number written saved, and for floating point numbers >> that's often a bit fiddly to do using decimal (%f). > > Not really. You have to know the trick, which is > > double f_savemeexactly = acos(0.0) *2; /* number we want to preserve to > machine precison */ > fprintf(fp, "%.*g\n", DBL_DIG, f_savemexactly); > > Then you can read it in with fscanf() or strtod(). If everything works > as specified, you should get an exact result back. Even if DBL_DIG were big enough, which it isn't, this still isn't guaranteed to work, because floating point conversion is not guaranteed to be exact even when it can be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-07 08:01 -0700 |
| Subject | Re: THANKS EVERYBODY FOR THE INFO |
| Message-ID | <87ioazsgti.fsf@kst-u.example.com> |
| In reply to | #63034 |
bilsch01 <king621@comcast.net> writes:
> So, I'll save and retrieve the data via fprintf and fscanf, and forget
> about the exact number of bytes. The computers will keep track of
> that part - right?. Ultimately there will be about 100 of these
> 12-item vectors (each having 4 float and 8 int) that I will have in
> the same file as the program that uses them. But for the job of
> selecting the particular vectors I will save them in a file one at a
> time using fprintf.
Please don't change the subject line when posting a followup, unless
there's a substantial change of topic (and in that case you should
probably start a new thread). Subject lines (this thread's subject was
originally "counting bytes") help readers follow discussions.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | gordonb.3gcai@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-06-07 05:02 -0500 |
| Message-ID | <Cb6dnfsq1tw7i-nInZ2dnUU7-cednZ2d@posted.internetamerica> |
| In reply to | #63031 |
> instead of lots of code to parse ASCII data). But then we got > a different machine (long-endian 64-bits instead of the lit- > tle-endian 32-bit machines I was used to) and none of the What is a long-endian 64-bit integer? What's the difference between that and a short-endian 64-bit integer or a 1-centimeter 64-bit integer? Did you mean wrong-endian? > * some machines store the less important bytes first, others > do it the other way round (and, if something has more than > 2 bytes, the number of theoretically possible ways to store > them grows with the factorial of the number of bytes), Machines generally store the *most significant* byte first (big-endian) or last (little-endian) except for the ones that don't (e.g. PDP11-endian). Granted, there are lots of possibilities, including going by *BIT* order, not *BYTE* order, yielding 32! ways to order a 32-bit integer. You will get considerable debate over which byte is "more important" (rather than "more significant"). For a 16-bit or 32-bit integer holding a pant size, the least-significant byte is arguably more important because pant sizes hardly ever go over 255, at least not in the USA, and the least-significant byte usually holds the entire number. For an amount of a paycheck (before deductions) say, a 32-bit integer number of cents, the most-significant byte may be considered most important because if it's wrong, the amount of the error is huge, and for some jobs, e.g. professional football players with a bi-weekly paycheck earning more than $4.3 million a year, that byte is actually used.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-07 15:32 +0200 |
| Message-ID | <ml1h2m$1dc$1@dont-email.me> |
| In reply to | #63031 |
On 07/06/15 00:31, Jens Thoms Toerring wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> Open the file as "rb" or "wb"; in Linux, it doesn't make a difference, but on
>> other platforms it will. You /may/ have need to transport your data file to a
>> different platform one day.
>
> If you do so please be aware that this DOES NOT store the date in
> a format that you're guaranteed to be able to read in on a dif-
> ferent computer. If you e.g. write them out on a 32-bit machine,
> transfer the resulting file to a 64-bit machine (even when run-
> ning the exact same operating system) and try to read the file
> in you could be in for a surprise. The number of bytes of a e.g.
> an int are not something that's the same on all computers. And
> neither is the way binary data are stored.
>
> So already your assumption that an "int" is always 4 bytes is
> wrong. It may be 2 bytes, 4 bytes or even more - it depends on
> the CPU. And neither is it a given that the data stored for an
> int start with the least or the most siginificant byte. So, un-
> less you know very well what you're doing refrain from trying
> to store data in binary a format. If you do you must understand
> what differences exist and how to deal with the resulting issues.
> Otherwise you may end up with data files that you can read in on
> one type of machine but not on a different one.
>
Using <stdint.h> fixed-size types (int32_t, etc.) does not solve all the
problems you mentioned here, but it is a step towards sorting /some/ of
them.
I also recommend using "_Static_assert" to confirm that the sizes are as
expected. So if you use:
struct
{
int32_t xf,
yf,
xof,
yof,
xm,
ym,
delay,
glength;
float w1,
w2,
w3,
k1;
} gdata;
_Static_assert(sizeof(int32_t) == 4, "Checking char size");
_Static_assert(sizeof(float) == 4, "Checking float size");
_Static_assert(sizeof(gdata) == 48, "Checking gdata size");
Then you are covered for most things (endianness being the glaring
omission - I don't know of any portable compile-time way to check that).
The use of "int32_t" rather than "int" gives you several benefits - it
guarantees the size of the type, and it guarantees the bit
representation. By checking that it is of size 4, we are not checking
the size of int32_t - it is guaranteed by the standards. We are
actually checking the size of "char", as an alternative to having
another include file and checking CHAR_BIT.
And by checking the size of the complete structure, we are also
confirming the alignment.
Note that this does not make the code more portable - but it provides
immediate compile-time feedback if there are portability problems.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-07 12:48 -0700 |
| Message-ID | <87eglns3jc.fsf@kst-u.example.com> |
| In reply to | #63037 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> _Static_assert(sizeof(int32_t) == 4, "Checking char size");
The string says "Checking char size", but it's checking the size of
int32_t.
The only way int32_t can have a size other than 4 bytes is if
CHAR_BIT > 8. You can replace the above with:
_Static_assert(CHAR_BIT == 8, "Checking CHAR_BIT");
> _Static_assert(sizeof(float) == 4, "Checking float size");
> _Static_assert(sizeof(gdata) == 48, "Checking gdata size");
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-07 23:05 +0200 |
| Message-ID | <ml2bjj$5jb$1@dont-email.me> |
| In reply to | #63046 |
On 07/06/15 21:48, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> _Static_assert(sizeof(int32_t) == 4, "Checking char size"); > > The string says "Checking char size", but it's checking the size of > int32_t. > > The only way int32_t can have a size other than 4 bytes is if > CHAR_BIT > 8. You can replace the above with: > > _Static_assert(CHAR_BIT == 8, "Checking CHAR_BIT"); That's pretty much exactly what I wrote - you must have missed that part of my mail. The only reason for using a check with sizeof(int32_t) rather than CHAR_BIT is to save yet another include file. In practice, I would be unlikely to use either as there is a very good chance that I would have a uint8_t reference in my code (they turn up in most of the programs I write), which already guarantees* that CHAR_BIT is 8. * I believe there may be a theoretical opening in the standards for an architecture that has CHAR_BIT not equal to 8 and yet still has a uint8_t type. But I am certain that I will never be using such a system. > >> _Static_assert(sizeof(float) == 4, "Checking float size"); >> _Static_assert(sizeof(gdata) == 48, "Checking gdata size"); > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-07 22:17 +0100 |
| Message-ID | <ml2cae$832$1@dont-email.me> |
| In reply to | #63048 |
On 07/06/15 22:05, David Brown wrote: <snip> > * I believe there may be a theoretical opening in the standards for an > architecture that has CHAR_BIT not equal to 8 and yet still has a > uint8_t type. But I am certain that I will never be using such a system. CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be greater than 8. The sizeof operator yields a size_t, which is the size (in bytes) of its operand, and size_t has an unsigned integer type, which means that it cannot represent fractional sizes. Since int8_t denotes a signed integer type with *exactly* 8 bits (see 7.20.1.1(1), which makes this crystal clear), on a system with CHAR_BIT greater than 8, it would have to have a fractional size. Since the sizeof operator is both (a) required to yield the size in bytes of its operand, and (b) unable to yield the size of an int8_t on a system with CHAR_BIT > 8, we have a contradiction. I deduce that such an implementation would not be conforming. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web