lwIP - A Lightweight TCP/IP stack - Bugs: bug #9191, Compiler problem with #define's
You are not allowed to post comments on this tracker with your current authentication level.
bug #9191: Compiler problem with #define's
Submitter: | None | ||
Submitted: | Wed 02 Jun 2004 03:53:58 PM UTC | ||
Category: | IPv4 | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Fixed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | None |
Thu 24 May 2007 04:38:59 AM UTC, comment #1: |
Tom Evans <tom_evans> |
Wed 02 Jun 2004 03:53:58 PM UTC, original submission:
This is most likely complier bugs. But since these problems exist in quite many mcu compilers it is probably a good thing to make it clearer to the compiler what we want it to do.
|
Anonymous |
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 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2006-10-25 | christiaans | Status | None | Fixed | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
The original (anonymous) poster should read the NC308 compiler manual.
In there it states that by default the compiler blatantly disobeys ANSI, and if ANSI operation is required the compiler flag "-fETI" is required. Quoting from the manual:
Function: Extends char type or signed char type data to int type data to perform operation (extension as per ANSI rules).
Supplement: In ANSI standards, the char-type or singed char-type data is always extended into the int type when evaluated. This extension is provided to prevent a problem in char-type arithmetic operations, e.g., c1 = c2 * 2 / c3; that the char type overflows in the middle of operation, and that the result takes on an unexpected value.
And in the case of the original "GETSHORT()" macro, the operation "s = *cp++ << 8" results in an explicit load of "s" with ZERO.
This is broken default compiler operation, but they do provide and document a fix.
If anyone knows who "Anonymous" is, please forward this information back to them.