standard doubt
 

Hi all. I'm writing a program wich will write some variables to an
output file. I do something like

int a =5;
fwrite(&a, sizeof(int), 1, my_file_ptr);

This will write an int to the file pointed by my_file_ptr. But i know
that the c standard does not specify the exact size in bytes for its
primitive type, as far as i know it only specifies that and int is an
integer type that rapresents a number with a sign, but different
implementations\operating systems can have different size for an int.

So this mean that my program will write a 32 bit integer with one
implementation and a 16 bit with another implementation. This would
also mean that the file generated by the program that is running in
one implementation will not be readable in another implementation,
unless the program knows also in which implementation the instance
that generated the file was running.
That is right? I do not want such a behavior. How can i solve this?

Re: standard doubt
 

On Dec 10, 9:17*am, raffamaiden <raffamai...@gmail.com> wrote:
> Hi all. I'm writing a program wich will write some variables to an
> output file. I do something like
>
> int a =5;
> fwrite(&a, sizeof(int), 1, my_file_ptr);
>
> This will write an int to the file pointed by my_file_ptr. But i know
> that the c standard does not specify the exact size in bytes for its
> primitive type, as far as i know it only specifies that and int is an
> integer type that rapresents a number with a sign, but different
> implementations\operating systems can have different size for an int.
>
> So this mean that my program will write a 32 bit integer with one
> implementation and a 16 bit with another implementation. This would
> also mean that the file generated by the program that is running in
> one implementation will not be readable in another implementation,
> unless the program knows also in which implementation the instance
> that generated the file was running.
> That is right? I do not want such a behavior. How can i solve this?

Serialize your data... e.g.

If you know you're using 32-bits of the data

unsigned char buf[4];
for (int x = 0; x < 4; x++) {
buf[0] = val & 0xFF;
val >>= 8;
}
outlen = fwrite(buf, 1, 4, outfile);

Of course smarter would be to write a function to store 32-bit ints to
a FILE then just call it when needed...

Tom

Re: standard doubt
 

Le 10-12-2010, raffamaiden <raffamaiden@gmail.com> a écritÂ*:
[SNIP: about portability and files]
> That is right?

Yes.

> I do not want such a behavior. How can i solve this?

You have to define your file format. They are severals...
You can choose text-oriented, or binary ones.
There is no 'best' solution. It depends on you needs.

Marc Boyer

Re: standard doubt
 

On 12/10/2010 6:17 AM, raffamaiden wrote:
> Hi all. I'm writing a program wich will write some variables to an
> output file. I do something like
>
> int a =5;
> fwrite(&a, sizeof(int), 1, my_file_ptr);
>
> This will write an int to the file pointed by my_file_ptr. But i know
> that the c standard does not specify the exact size in bytes for its
> primitive type, as far as i know it only specifies that and int is an
> integer type that rapresents a number with a sign, but different
> implementations\operating systems can have different size for an int.
>
> So this mean that my program will write a 32 bit integer with one
> implementation and a 16 bit with another implementation.

How about int32_t ?


--
Tim Prince

Re: standard doubt
 

On 12/10/2010 02:39 PM, Tim Prince wrote:
> On 12/10/2010 6:17 AM, raffamaiden wrote:
>> Hi all. I'm writing a program wich will write some variables to an
>> output file. I do something like
>>
>> int a =5;
>> fwrite(&a, sizeof(int), 1, my_file_ptr);
>>
>> This will write an int to the file pointed by my_file_ptr. But i know
>> that the c standard does not specify the exact size in bytes for its
>> primitive type, as far as i know it only specifies that and int is an
>> integer type that rapresents a number with a sign, but different
>> implementations\operating systems can have different size for an int.
>>
>> So this mean that my program will write a 32 bit integer with one
>> implementation and a 16 bit with another implementation.
>
> How about int32_t ?

What about endianness?

Re: standard doubt
 

First off, thanks for the answers.

> *You have to define your file format. They are severals...
> *You can choose text-oriented, or binary ones.
> *There is no 'best' solution. It depends on you needs.

I want to use a binary file format because i feel the final file will
be smaller and doesn't require atoi() and other stuff to retrieve the
data.
An integer should be stored as 32-bit.

>Serialize your data... e.g.
>If you know you're using 32-bits of the data
>
>unsigned char buf[4];
>for (int x = 0; x < 4; x++) {
> buf[0] = val & 0xFF;
> val >>= 8;
>}
>
>outlen = fwrite(buf, 1, 4, outfile);
>
>Of course smarter would be to write a function to store 32-bit ints to
>a FILE then just call it when needed...

I like this solution, but I have few more questions: Is 'char'
guaranteed to be exactly 1 byte by the standard? Because if not that
would not make sense.

Also another question: in your example my integer, for which i use
only the last 32-bits whatever its size in memory is, would be in the
variable "val". How about encoding? Does the C standard (let it be
C90) specify how an integer should be encoded in memory, or not? If
not, suppose i'm running my program in two implementations A and B. A
use two's complement encoding, while B use sign and magnitude. So if A
save the integer with the above c code, it will save exactly 32 bits,
but B will recognize another number because it use another encoding in
the same 32-bits.

Also, shouldn't buf[0] be buf[x]?

Re: standard doubt
 

In article
<0c976661-b381-4ffb-ab58-1327234aa311@t8g2000prh.googlegroups.com>,
raffamaiden <raffamaiden@gmail.com> wrote:

> Hi all. I'm writing a program wich will write some variables to an
> output file. I do something like
>
> int a =5;
> fwrite(&a, sizeof(int), 1, my_file_ptr);
>
> This will write an int to the file pointed by my_file_ptr. But i know
> that the c standard does not specify the exact size in bytes for its
> primitive type, as far as i know it only specifies that and int is an
> integer type that rapresents a number with a sign, but different
> implementations\operating systems can have different size for an int.
>
> So this mean that my program will write a 32 bit integer with one
> implementation and a 16 bit with another implementation. This would
> also mean that the file generated by the program that is running in
> one implementation will not be readable in another implementation,
> unless the program knows also in which implementation the instance
> that generated the file was running.
> That is right? I do not want such a behavior. How can i solve this?

As others have said, the better solution may be to define the format of
your file handle all reasonable variations. I recently took another
approach when I needed to work with the very poorly designed .stl file
format. I needed to have 2 byte unsigned, 4 byte unsigned, 4 byte floats
and 50 byte structures, and I needed to compile and run on Windows, Mac
and Unix. At the start of the program I have lines such as:

assert(sizeof(unsigned) == 4);

Then if the asserts fail, I can adjust compiler switches in my makefile
accordingly.

Re: standard doubt
 

Le 10-12-2010, raffamaiden <raffamaiden@gmail.com> a écritÂ*:
> First off, thanks for the answers.
>
>> Â*You have to define your file format. They are severals...
>> Â*You can choose text-oriented, or binary ones.
>> Â*There is no 'best' solution. It depends on you needs.
>
> I want to use a binary file format because i feel the final file will
> be smaller and doesn't require atoi() and other stuff to retrieve the
> data.
> An integer should be stored as 32-bit.

OK

>>Serialize your data... e.g.
>>If you know you're using 32-bits of the data
>>
>>unsigned char buf[4];
>>for (int x = 0; x < 4; x++) {
>> buf[0] = val & 0xFF;
>> val >>= 8;
>>}
>>
>>outlen = fwrite(buf, 1, 4, outfile);
>>
>>Of course smarter would be to write a function to store 32-bit ints to
>>a FILE then just call it when needed...
>
> I like this solution, but I have few more questions: Is 'char'
> guaranteed to be exactly 1 byte by the standard? Because if not that
> would not make sense.

It is not guaranteed, but it is very common.
You have other issues, stricly looking at the standart, like
the endianness (but the given code should be robust), or the
encoding of signed values (2-complement is not the only one).
But, considering 'common' architectures, you can assume
that char are 8-bits long, and 2-complement. Moreover,
the value CHAR_BIT gives you the number of bits of a char.

Marc Boyer

Re: standard doubt
 

In article <0c976661-b381-4ffb-ab58-1327234aa311@t8g2000prh.googlegroups.com>,
raffamaiden <raffamaiden@gmail.com> wrote:
....
>So this mean that my program will write a 32 bit integer with one
>implementation and a 16 bit with another implementation. This would

The standard does not guarantee the existence of an implementation that
has 32 bit integers, nor of one that has 16 bit integers. So, you can't
be sure of this (what you claim in the quoted paragraph) - based solely
on the standard.

And of course, that (the standard) is all that matters in this newsgroup.

--
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

Re: standard doubt
 

On Fri, 10 Dec 2010 09:57:54 -0500, raffamaiden <raffamaiden@gmail.com>
wrote:

> I like this solution, but I have few more questions: Is 'char'
> guaranteed to be exactly 1 byte by the standard?

Yes, but it doesn't guarantee that "byte" means what you think it does.
The standard requires a byte to be *at least* 8 bytes. It doesn't forbid
C from being implemented on architectures where the smallest addressable
unit of memory (or disk) is, e.g., 64 bits, nor does it place any
requirement on the size of a "byte" in implementations for that
architecture. I have used (and maintained the C compiler for) a machine
with 10-bit bytes, 10-bit chars, 20-bit ints.
--
Morris Keesan -- mkeesan@post.harvard.edu