standard doubt

[Nobody]

If you assume that *some* predefined signed integer type is 32-bit two's
complement, that's probably ok for the vast majority of current
(non-embedded) systems. Assuming that "int" is such a type is unwise
and unnecessary.

It's unnecessary if you don't mind copying data to/from actual "int"s
every time you call something which wants an "int *".

Personally, if I'm writing for desktop/server/32-bit-embedded, I'll assume
that "int" is 32-bit two's complement. Anything else may as well not exist
until I see a concrete reason for considering its existence.

I'll also assume that "int" is the correct type for array indices (and
passing to malloc) unless support for more than 2^31 entries is at least
plausible, in which case I'll use "long" unless I'm explicitly required
to care about Win64.

I certainly wouldn't assume little-endian representation for anything to
be shared with different systems. x86 happens to be dominant today, but
there's not guarantee that it always will be; there are still a
significant number of SPARC systems out there. And it's a solvable
problem anyway; you don't *have* to depend on a particular endianness.
(This is why "network byte order" exists.)

I wouldn't normally rely upon it to the extent of sprinkling fread/fwrite
(etc) about the code. I'd isolate the calls so that adding support for a
big-endian system would amount to "add a version of this source file
which does byte swapping".

OTOH, I wouldn't completely rule out:

struct the_data *p = mmap(...);

simply because it would make the program impossible to port to an
"unusual" system without a major rewrite. Sometimes, portability just
costs too much.

Alignment is an issue only for in-memory data; it's irrelevant for
reading and writing files.

It's relevant if your I/O model is "mmap() the file" and you don't want to
litter the code with "packed" qualifiers and take a performance hit.

 

[Nick Keighley]

raffamaiden <[email protected]> writes:

[the OP is writing data using fwrite() and relising the snags of raw
binary data]


and why does it need to be small? One technique is to write a text
file and uncompress it on the fly. I understand Open office saves its
data in XML and then gzips it. It obviosly works for them.

If you use a binary file format, either you'll have to define the
exact format (and translate to and from that format when accessing
the file), or you'll have to give up on being able to read the file
on other systems.

and "other system" may include two different versions of the same
compiler. Or even changes to flags (the eldrich "nopack") or
optimisation.

 Straight binary (fwrite'ing structs directly,
for example) can make sense for files that will be used *only* by the
same program on the same system.

with the same caveat about "same system"

Text is far more portable, and you may find that the space and time
overhead of using text rather than binary isn't that much of an issue.

there are binary formats that are nearly as portable. XDR, ASN.1 with
approriate encoding rules.

<snip>

 

[Nick Keighley]

If you use a binary file format, either you'll have to define the
exact format (and translate to and from that format when accessing
the file), or you'll have to give up on being able to read the file
on other systems.  Straight binary (fwrite'ing structs directly,
for example) can make sense for files that will be used *only* by the
same program on the same system.

Text is far more portable, and you may find that the space and time
overhead of using text rather than binary isn't that much of an issue.

Why?  I'm not saying you're wrong, but why 32 bits in particular?

See <stdint.h> for definitions of types of particular sizes.  uint32_t
might be the best thing for your purposes, at least if you don't need
negative values.

where is the problem to build a standard type for unsigned 32 bits e.g.
uint32_t
that has, the same bit structure, big endian or little endian
that has, the same +-*/ [2 complement]
don't know enougt for alignement iussue

I'm not sure what you're asking. Keith was saying why does an int have
to be 32 bits? If you want 32 bits then uint32_t will solve many of
your problems in practice. You've chosen a size. You still have endian
problems. Soyou need to choose an endianess and stick to it in your
read and write functions. 2 complement is almost universal nowadays.
If you happen to be on a ones complement or signed magnitude then
you're going to have to a bit more work. Alignment doesn't matter in
the case of reading/writing files.

if a program can use such
uint32_t, uint16_t, uint8_t
it has few problem in portability at last for me

you still need toworry about endianess. Intel goone way motorola and
many risc chips another.

is the problem translate one +-*/ 2 complement in some other sys +-*/?
is the problem translate the big endian of cpu, in little endian and viceversa?
where are the problems?
are the in code speed?

if you're doing filei/o then speed doesn't really matter. If you force
improper alignment in your code it may run very slowly (or not at all)

the only problem i see on it [in case uint32_t]
is the cpu can not have registers of 32 bits
so could be not fast implement all in software using e.g registers 16 bits
not i think on it...

a 16 bit machine may be slow if you use 32 bit stuff but if you need
32 bits then pretending you don't may be a mistake.

and if some PC has only one cpu has only 64bits registers? this seem more hard;
is it possible define one 32bits type, and all goes well too
for arrays of 32bits type using only one 64 type?

<snip>

 

[Keith Thompson]

An integer should be stored as 32-bit.

Why?  I'm not saying you're wrong, but why 32 bits in particular?

See <stdint.h> for definitions of types of particular sizes.  uint32_t
might be the best thing for your purposes, at least if you don't need
negative values.

where is the problem to build a standard type for unsigned 32 bits e.g.
uint32_t
that has, the same bit structure, big endian or little endian
that has, the same +-*/ [2 complement]
don't know enougt for alignement iussue

I'm not sure what you're asking. Keith was saying why does an int have
to be 32 bits?

[...]

No I was asking why raffamaiden said "an *integer* should be stored as
32-bit". There are integer types other than int.

 

[Ian Collins]

uint32_t has the size: 32 bits ok
where is the problem in define for uint32_t the endianess too?
Hardware.

i read one book that say the endianess has effect only for the way
the data is represented in the memory
good i say just
to see each uint32_t number as one little-endian number
and this for each computer

But it isn't. So we're stuck with two schemes.

 

[Nick Keighley]

where is the problem to build a standard type for unsigned 32 bits e.g..
uint32_t
that has, the same bit structure, big endian or little endian
that has, the same +-*/ [2 complement]
don't know enougt for alignement iussue

I'm not sure what you're asking. Keith was saying why does an [integer] have
to be 32 bits? If you want 32 bits then uint32_t will solve many of
your problems in practice. You've chosen a size. You still have endian
problems. So you need to choose an endianess and stick to it in your
read and write functions. 2s complement is almost universal nowadays.
If you happen to be on a ones complement or signed magnitude then
you're going to have to a bit more work. Alignment doesn't matter in
the case of reading/writing files. [...]
you still need to worry about endianess. Intel go one way motorola and
many risc chips another.

uint32_t has the size: 32 bits ok
where is the problem in define for uint32_t the endianess too?

because it isn't. uint32_t doesn't specify the endianness of the
internal representation.

i read one book that say the endianess has effect only for the way
the data is represented in the memory

and you're going to have to deal with that when do i/o

good i say just
to see each uint32_t number as one little-endian number
and this for each computer

yes but the world doesn't actually work that way.

for example
this means that 0x4 has the same uint32_t data rappresentation each computer
that in hex should be 0x4, 0, 0, 0 see all as 4 uint8_t numbers

yes but it doesn't. It may appear in memory as 0, 0, 0, 0x4

traslate and execute one operation on bits from little-endian to cpu-endian
if the cpu has the register of 32 bits and 8 bits where doing operations
not should slow down the sys much

lost me. What you can do is use shifts and masks (and I say you
should!). They extract the bytes in the right order.

write (x & 0xff);

always writes the least significant 8 bits no matter how the number is
stored internally.

in pratice
if i have the number in hex little endian uint8_t rapresentation
1h,2h,3h,4h [this means the number 0x04030201]
and i have to mult it with the number in hex 3h
in one cpu that is in big endian there is one operation more:
traslate 1h,2h,3h,4h to -> 4h,3h,2h,1h
and the usual mult the memory  "4h,3h,2h,1h" for "3h"

we may be singing from the same song sheet (in agreement) but I'm not
sure

for unsigned i read in the book the rapresentation
not has 1-complement 2-complement etc problem
because it is for signed numbers

the book (or you) is mistaken. Endianess problems are the same for
signed and unsigned.

i not say the above only for the problem of write one file
but for each program use uint32_t

i try if is possible to have one set of types have the same rappresentation
in the memory
and where operations on them has the same final result, in each computer

can't be done. The actual silicon is different.


<snip>

 

[Ian Collins]

"Nick Keighley" ha scritto nel messaggio



yes the realty
the only side you not consider that software is more expensive
than the hardware (at last i think so)

so hardware will go to make easy software writing
and so portability

It's 30 odd years since Intel went one way and Motorola went the other,
so it looks like you are in for a long wait.

 

[Nick Keighley]

not really. Otherwise we'd all be out of a job and Microhard would be
a chip manufacturer.

It's 30 odd years since Intel went one way and Motorola went the other,
so it looks like you are in for a long wait.

I'm betting the first star ship will have endianess problems

 

[Chris H]

In message <[email protected]

I'm betting the first star ship will have endianess problems

No it won't! The pointy end will be the front and the blunt end will be
the back....

 

[Niklas Holsti]

In message <[email protected]


No it won't! The pointy end will be the front and the blunt end will be
the back....

Not necessarily. In some designs, the starships fly with the blunt end
first, because the blunt end is a shield of ice to protect the rest of
the ship from erosion by interstellar dust.

So the endianness battle may continue...

 

[Chris H]

Not necessarily. In some designs, the starships fly with the blunt end
first, because the blunt end is a shield of ice to protect the rest of
the ship from erosion by interstellar dust.

So the endianness battle may continue...

Ok you asked for it .... Go for your Light Sabre!!!!
))