Re: [boost] [endian] Refresh based on comments received

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2006-06-09 10:14:03

----Original Message----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of me22 Sent: 09 June
2006 14:51 To: boost_at_[hidden]
Subject: Re: [boost] [endian] Refresh based on comments received

> On 6/9/06, Martin Bonner <martin.bonner_at_[hidden]> wrote:
>> No.  They all have AT LEAST 8 bits, but there are certainly C
>> implementations with 9-bit char and 32-bit char.  I don't know if
>> any of these have C++ compilers (but the standard certainly permits
>> it).  (You might of course decide to explicitly limit your library
>> to 8-bit char platforms only.) 
>> 
> How do those C implementations handle I/O?  Does fgetc actually give
> the next 9 or 32 bits of the file?

Well, some of them (DSPs) are freestanding implementations and don't
/have/ fgetc.  But in general, yes.  Of course, on such systems the file
will be divided into 9 or 32 bit sized chunks.  (Which makes file
transfer interesting).

> If, for example, the sockets implementation actually filled all 9 bits
> in a byte on a recv, I could see that being a portability nightmare...

The sockets implementation receive octets down the wire (and they are
called octets not bytes because the designers were aware of non-8-bit
bytes).

recv will store each octet into a byte (which C and C++ guarantees is
big enough).

send might just transmit the low eight bits of each byte as the octet,
or it might fail if higher bits are non-zero.

-- 
Martin Bonner
Martin.Bonner_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]