Author: Robert Hyatt
Date: 19:40:57 01/12/03
Go up one level in this thread
On January 12, 2003 at 02:13:57, Miguel A. Ballicora wrote: >On January 11, 2003 at 19:26:43, Robert Hyatt wrote: > >>On January 11, 2003 at 16:44:26, Miguel A. Ballicora wrote: >> >>>On January 11, 2003 at 11:40:00, Robert Hyatt wrote: >>> >>>>What do you suppose will happen when we have 64 bit machines with 128 bit >>>>integers? Care to guess what that will do to portability when you try to >>>>send binary files around between a 32 bit and a 64 bit architecture? Then >>>>you might begin to see _the_ problem with the data types as they exist. >>> >>>To send binary files portably you have to do it byte by byte, so it is the same >>>no matter what system you use. You cannot send an int32 as a block, that is not >>>portable at all no matter what system you use. >> >>Sure it is. It is only non-portable on machines with different endianess. > >It is not portable on machines with different endianess, so sure it is not >portable. At least on _one_ machine, I can't write a file in one language, and read it in C, with reliability. Particularly if there are bytes/words with groups of bits that mean different things. I can't use bit-fields for that as on one machine bitfields might start at one end, on another they start at the other end. There are enough of those to make me pull my hair out with all the different machines I work on. > >>But even with that, if I write an "int" how many bytes do I write? > >If you make it portable, you can't write an int and you can't write int32_t >either. You have to write it byte by byte. Only if I am crossing architectures. But what if someone writes a file in FORTRAN (on a Cray) and I want to read it with a C program, something that is pretty common. I can ignore endianness, but I can't use bitfields, for one example. > >>>>>Even if you want something very specific you can use unsigned bitfields so they >>>>>will wrap after 12, 17 or whatever bits you want. Generally using the 'and' is >>>>>so simple that it doesn't justify to be bothered. >>>> >>>> >>>>Sorry but that is wrong. Bitfields are not well-defined in the standard. >>>>Which end do they start from? You instantly see the problem with using them. >>>>And trying to put them into a structure adds a random amount of padding, >>>>the random amount being the unused bits in a native "thing" the compiler has >>>>to use, which is yet another problem. >>> >>>It does not matter if you use one bitfield per structure just to use a number >>>with "x bits" if you really want that number defined in that way. >>> >>>Miguel >> >>Doesn't matter which end of a word a bit field starts on? Doesn't matter which >>order the bitfield variables appear in? To an operating systems person it >>matters a _bunch_ because the definitions for O/S tables are pre-defined and I >>just want to access them. And I can't... > >That is using bitfields to match bits, which is not portable. It is not what I >said. Anyway it is not critical for the discussion because as I said before, it >is preferred to use the classical way for bits manipulation (& >> etc.), and the >bitfield can be used only as ints or (hence, portable only up to 16 bits). > >Miguel If it were _consistent_ it would be far more usable for cross-language data sharing. As it is, I simply don't use them because they are worthless in that regard.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.