RE: [lwip-users] Problem With dns.c Using 32-Bit Compilers

[Grubb, Jared]

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: address@hidden [mailto:address@hidden 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