lwIP - A Lightweight TCP/IP stack - Bugs: bug #52611, Incorrect use of ctype macros?
You are not allowed to post comments on this tracker with your current authentication level.
bug #52611: Incorrect use of ctype macros?
Submitter: | Mike Kleshov <kleshov> | ||
Submitted: | Thu 07 Dec 2017 09:22:27 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | Fixed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Thu 07 Dec 2017 11:03:12 AM UTC, comment #11: |
Dirk Ziegelmeier <dziegel> |
Thu 07 Dec 2017 10:57:46 AM UTC, comment #10: One more thing: enclosing macro arguments in parentheses would be a good idea, I think. |
Mike Kleshov <kleshov> |
Thu 07 Dec 2017 10:49:29 AM UTC, comment #9: Looks good.
|
Mike Kleshov <kleshov> |
Thu 07 Dec 2017 10:45:35 AM UTC, comment #8: I see your point now.
|
Axel Lin <axellin> |
Thu 07 Dec 2017 10:25:40 AM UTC, comment #7: Looking at the code, I can see that right now the use of ctype macros in ip4_addr.c is broken. It can lead to undefined behaviour. It became broken when local implementation of those macros was replaced with reference to standard macros, which behave differently.
|
Mike Kleshov <kleshov> |
Thu 07 Dec 2017 10:20:45 AM UTC, comment #6: To make it clear, the previous cast to int is for !LWIP_NO_CTYPE_H case.
|
Axel Lin <axellin> |
Thu 07 Dec 2017 09:46:18 AM UTC, comment #5: I don't understand this. If it's wrong in the caller, why the cast to int in the first place? To fix compiler warnings? Shouldn't they be fixed in the caller?
|
Mike Kleshov <kleshov> |
Thu 07 Dec 2017 09:38:21 AM UTC, comment #4: In this case, cast to unsigned int does not help. It's wrong anyway in the caller and needs fix the caller. |
Axel Lin <axellin> |
Thu 07 Dec 2017 09:31:43 AM UTC, comment #3: The reference you are referring to also says "The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF".
|
Mike Kleshov <kleshov> |
Thu 07 Dec 2017 09:29:19 AM UTC, comment #2: Can it be that in his setup, the implementation of the given functions are by macros that are potentially broken? |
Stian Sebastian Skjelstad <mywave> |
Thu 07 Dec 2017 09:26:34 AM UTC, comment #1: The function signature says they take an int as argument, so the cast is correct. See:
|
Dirk Ziegelmeier <dziegel> |
Thu 07 Dec 2017 09:22:27 AM UTC, original submission:
A recent commit casts arguments to int before invoking ctype macros:
|
Mike Kleshov <kleshov> |
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 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-12-07 | dziegel | Status | Wont Fix | Fixed | |
Open/Closed | Open | Closed | |||
2017-12-07 | axellin | Attached File | - | Added 0001-Cast-character-to-unsigned-char-for-isdigit-isxdigit.patch, #42590 | |
2017-12-07 | kleshov | Open/Closed | Closed | Open | |
2017-12-07 | dziegel | Status | None | Wont Fix | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-3230.
Corresponding source code
Didn't see that "The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF" part - these functions are fundamentally broken and should be fixed.
Applied Axel's patch which ensures valid input range, respecting Mike's comments.
Thanks for insisting, Mike!