lwIP - A Lightweight TCP/IP stack - Bugs: bug #26134, Insert a dummy u16_t field to...
You are not allowed to post comments on this tracker with your current authentication level.
bug #26134: Insert a dummy u16_t field to prevent alignment exceptions
Submitter: | Zhenwei Chu <blackfin> | ||
Submitted: | Thu 09 Apr 2009 02:06:54 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Invalid |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 1.3.0 |
Jump to the original submission
Wed 15 Apr 2009 08:44:01 PM UTC, comment #6: |
Simon Goldschmidt <goldsimon> |
Wed 15 Apr 2009 08:00:39 PM UTC, comment #5: Yes. ETH_PAD_SIZE is much flexible.It just got overlooked in the migration. It's good enough for eth_hdr.
|
Srinivas Gollakota <gollakota> |
Mon 13 Apr 2009 08:46:53 PM UTC, comment #4: What exactly are you trying to solve with this? The struct etharp_hdr is the exact representation of the message as defined in RFC 826. By inserting "dummy" or "unused" fields, you only will break everyone else's port except yours. Which brings us back to the first question.
|
Simon Goldschmidt <goldsimon> |
Mon 13 Apr 2009 06:53:41 PM UTC, comment #3: one more change required:
|
Zhenwei Chu <blackfin> |
Fri 10 Apr 2009 05:58:12 AM UTC, comment #2:
|
Simon Goldschmidt <goldsimon> |
Thu 09 Apr 2009 02:44:46 PM UTC, comment #1: Why not just define ETH_PAD_SIZE?
|
Kieran Mansley <kieranm> |
Thu 09 Apr 2009 02:06:54 PM UTC, original submission:
Insert a dummy u16_t field to prevent alignment exceptions
|
Zhenwei Chu <blackfin> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-04-15 | goldsimon | Status | None | Invalid | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
That is the case with most architectures and the reason 'packed structs' have been introduced to C. (Forgive me if you already know this): with packed structs, the compiler basically accesses memory byte-by-byte and reconstructs the u32_t in a register. This is slow but there is no workaround for this as the structure layout is defined by the network protocol (we cannot just change it in the lwIP code).
lwIP ports can control structure packing either through defines (PACK_STRUCT_BEGIN / PACK_STRUCT_FIELD / PACK_STRUCT_STRUCT / PACK_STRUCT_END) or through include files (PACK_STRUCT_USE_INCLUDES). Both ways can be found as example either in the win32 or unix port. There are some compilers that don't support structure packing, but these are so rare that we cannot afford to support them (and these are really, really rare so I doubt that is the case for you).
I'll close this as invalid. Please don't hesitate to reply to the lwip_devel list on further questions.