patchlwIP - 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: 

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...

Simon Goldschmidt <goldsimon>
Group administrator
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>
Group administrator
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,
u16_t is forced for mem_size_t, even when MEM_SIZE cannot fit into a type as small as u16_t.
The following patch duplicates the test used if MEM_USE_POOLS is false, and which, if MEM_SIZE > 64000, uses u32_t for mem_size_t.

This allows MEM_USE_POOLS while MEM_SIZE > 0xFFFFU without an overflow error.

Patch below:

diff --git a/src/include/lwip/mem.h b/src/include/lwip/mem.h
index ff208d25..76aeda56 100644
--- a/src/include/lwip/mem.h
+++ b/src/include/lwip/mem.h
@@ -52,8 +52,17 @@ typedef size_t mem_size_t;

 #elif MEM_USE_POOLS

+/* MEM_SIZE would have to be aligned, but using 64000 here instead of
+ * 65535 leaves some room for alignment...
+ */
+#if MEM_SIZE > 64000L
+typedef u32_t mem_size_t;
+#define MEM_SIZE_F U32_F
+#else
 typedef u16_t mem_size_t;
 #define MEM_SIZE_F U16_F
+#endif /* MEM_SIZE > 64000 */
+#endif

 #else


ODH <odh>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by odh (Submitted the item)
  •  

    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 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code