lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Williamson
Subject: Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers
Date: Thu, 28 Aug 2008 15:21:38 -0400
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

>> IMHP the appropriate pack/unpack files of each compiler should be 
>> included somewhere, so that any new user can use it :)
>>     
>
> Included in the lwIP distro? I don't think so: Compilers often change and we 
> can't keep a list of all the compilers in the world. It's up to the one that 
> ports lwIP to a specific platform to define the correct structure packing 
> macros/files.
>
> Simon
>   
Actually, I happen to be a developer that uses a compiler that doesn't
even have structure packing (TI's Code Composer Studio for their DSP
products), it tends to pad bytes quite often to force all alignments
within a struct to 4 byte boundaries...  We've ported lwIP awhile ago
but constantly run into the issue of protocol fragments represented as
structs and it's always a menace to find them.  Then we need to "fix" it
in our code in such a way to allow us to still "pull" from the lwIP CVS
tree for new features and bug fixes.  The DNS implementation was one of
them.  Easy to fix once you recognize the problem, but a deviation from
the lwIP baseline.

It would be really handy, if, somehow, there could be a sys_arch style
hook or macro for protocol fragment encoding/decoding that would default
to structure overlaying, but let you override it with byte-by-byte
copying to a compiler friendly data structure if you need to.

I certainly agree that the code shouldn't have a million #ifdefs for
handling compiler idiosyncrasies, but something crafty like that would
go along way to beating down this sort of discussion, and easing the
port to other platforms.... FWIW.

-Mike



Attachment: michael_williamson.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]