lwIP - A Lightweight TCP/IP stack - Patches: patch #10088, allow "typedef u32_t...
You are not allowed to post comments on this tracker with your current authentication level.
patch #10088: allow "typedef u32_t mem_size_t" when MEM_SIZE > 640000L and MEM_USE_POOLS
Submitter: | ODH <odh> | ||
Submitted: | Wed 21 Jul 2021 08:51:33 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Works For Me | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Planned Release: | None |
Fri 13 Oct 2023 01:56:22 PM UTC, comment #4: |
Simon Goldschmidt <goldsimon> |
Fri 13 Oct 2023 12:43:52 PM UTC, comment #3: When, for example, you have: MEM_SIZE == 132kB, you then have statements in mem_init(...) like: "mem->next = MEM_SIZE_ALIGNED;" which is assigning the value 0x00010000U to a 16-bit variable of type mem_size_t. This is obviously wrong, and obviously not what the author of the software is expecting to happen - they were expecting to be able to always fit the value of MEM_SIZE into a variable of type mem_size_t. This patch corrects this situation for cases in which MEM_SIZE_ALIGNED is, or is likely to be unable to fit within a 16-bit mem_size_t by using 32-bits for mem_size_t. |
ODH <odh> |
Thu 12 Oct 2023 06:41:03 PM UTC, comment #2: What do you need this for? Pool elements have u16_t as member size, so what do you need mem_size_t to be u32_t for? |
Simon Goldschmidt <goldsimon> |
Wed 04 Aug 2021 12:20:22 PM UTC, comment #1: Title needs changed: 640000 -> 64000 (one too many zeroes) |
ODH <odh> |
Wed 21 Jul 2021 08:51:33 PM UTC, original submission:
Currently, while MEM_USE_POOLS is true,
|
ODH <odh> |
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.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2023-10-12 | goldsimon | Status | None | Works For Me |
Powered by Savane 3.13-02a9.
Corresponding source code
My point is: wouldn't it be better to assert that with MEM_USE_POOLS, MEM_SIZE is never > 64000? Because having mem_size_t == u32_t really does not make any sense when you can't allocate elements > 65535 bytes because the pool implementation uses u16_t.
On the other hand, using MEM_SIZE at all does not make sense for MEM_USE_POOLS, and thus, it probably doesn't hurt to keep mem_size_t consistent, no matter if MEM_USE_POOLS is 1 or 0...