Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Malcolm McLean Newsgroups: comp.lang.c Subject: Re: C23 thoughts and opinions Date: Wed, 29 May 2024 01:03:02 +0100 Organization: A noiseless patient Spider Lines: 21 Message-ID: References: <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com> <87msoh5uh6.fsf@nosuchdomain.example.com> <87y18047jk.fsf@nosuchdomain.example.com> <87msoe1xxo.fsf@nosuchdomain.example.com> <87ikz11osy.fsf@nosuchdomain.example.com> <87sey1y7w8.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 29 May 2024 02:03:02 +0200 (CEST) Injection-Info: dont-email.me; posting-host="c22f2eb63f21eaf90e4648553f85da9b"; logging-data="870568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19J7QlukmMt9qIIKZh0Q3Ih8RoKgz11lcU=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:4loSjRBeDrMiCKFfDYcziWsk1bw= Content-Language: en-GB In-Reply-To: <87sey1y7w8.fsf@nosuchdomain.example.com> Bytes: 2326 On 28/05/2024 21:54, Keith Thompson wrote: > Keith Thompson writes > > And of course CHAR_BIT is the byte size on the target (relevant for > cross-compilers). In the odd case where CHAR_BIT is different on the > host and target systems, the embedded file needs to be one that could be > used on the target (if the target supports files). > > It's probably reasonable for an implementation to support *only* > CHAR_BIT as the embed element width, and not to provide a mechanism to > change it. > If you pass my JPEG loader, for example, a binary created by zero-padding the most significant bits in a plarform where CHAR_BIT is not 8, it should work as intended. Unfortunately I don't have such a machine to actually test this. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm