I'm certainly not arguing that lwIP should support any of those odd architectures. I was correcting the statement that "ARM cannot access bytes".
For curiousity's sake: the C standard defines sizeof(char)==1, and the unit is "byte". But, a "byte" is not necessarily 8 bits, nor is it even necessarily a multiple of 8. (That's why the RFC's I can think of all talk about "octets" and not "bytes"). The only guarantee is that you can walk memory with a (char*) and hit every single bit, with no gaps, and no incoherencies (there's a "fun" discussion here about C on the PDP-10 (word size==36 bits): http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6 ) Jared -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Auerbach Sent: Tuesday, September 02, 2008 11:15 To: 'Mailing list for lwIP users' Subject: RE: [lwip-users] Problem With dns.c Using 32-Bit Compilers Are there really any processors in the last 10-20 years that didn't have bytes that are 8-bits? To be semantically correct, C defines char (not byte). Sizeof char is always 1, and if bytes have 8-bits, then the compiler is guaranteed to load chars as you stated. Then it follows that macros are possible that do 2 char accesses. The macros I posted that do this work - they do 2 separate byte reads and form the final int. This should work everywhere. Bill _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
