Boost logo

Boost :

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: +44 (0)1223 203894

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk