CubeMX generates lwIP-file lwippools.h that does not work when you include lwip.h from a .cpp file

[t.decker]

CubeMX (at least since version 6.7, maybe longer) generates the lwippools.h with

#ifdef __cplusplus
extern "C" {
#endif

which gives empty code if you use the C compiler. But if you include the lwip.h in a .cpp file, it won't compile.

This is because lwippools.h is not used as standard header file but is included inside a enum-declaration/definition in memp.h (via memp_std.h):

typedef enum {
#define LWIP_MEMPOOL(name,num,size,desc)  MEMP_##name,
#include "lwip/priv/memp_std.h"
  MEMP_MAX
} memp_t;

And now if you let a C++ compiler run over this, you have a extern "C" {...} inside your enum. The long list of errors begins with:

In file included from ../Middlewares/Third_Party/LwIP/src/include/lwip/priv/memp_std.h:142,
                 from ../Middlewares/Third_Party/LwIP/src/include/lwip/memp.h:54,
                 from ../LWIP/App/lwip.h:31,
                 from ../Application/Ethernet/EthernetConnection.cpp:13:
../LWIP/Target/lwippools.h:32:2: error: expected identifier before 'extern'
   32 |  extern "C" {
      |  ^~~~~~
../LWIP/Target/lwippools.h:32:2: error: expected '}' before 'extern'

For the moment I always remove the #ifdef __cplusplus part from that file after generating in CubeMX, but maybe you want to fix this in the code generator?

[Piranha]

I added this topic to my network issue list. So CubeMX is generating this:

#ifdef __cplusplus
 extern "C" {
#endif
 
/* USER CODE BEGIN 0 */
/* Warning 1: The following code is only given as an example */
/* You can use this example code by uncommenting it */
/* -------------- EXAMPLE of CODE ------------------------*/
/* Define three pools with sizes 256, 512, and 1512 bytes */
/* 
#if MEM_USE_POOLS
LWIP_MALLOC_MEMPOOL_START
LWIP_MALLOC_MEMPOOL(20, 256)
LWIP_MALLOC_MEMPOOL(10, 512)
LWIP_MALLOC_MEMPOOL(5, 1512)
LWIP_MALLOC_MEMPOOL_END
#endif
*/
/* -------------- END of EXAMPLE of CODE -----------------*/
 
/* USER CODE END 0 */
 
#ifdef __cplusplus
}
#endif

In addition to the main flaw, I also noticed a "fun" fact related to 1512 bytes...

https://lwip.fandom.com/wiki/Custom_memory_pools

For example, if your chunk sizes are 256 (for small blocks), 512 (for medium blocks) and 1512 (for full Ethernet frames)...

The Ethernet header ir 14 B, CRC is 4 B and VLAN tag is 4 B. Therefore with the standard Ethernet MTU of 1500 bytes, the Ethernet frame size is 1514, 1518 or 1522 bytes. Someone made an error long ago and half of the world is just replicating it without any thinking, including the ST's "geniuses".

[t.decker]

Any news on this? Hasn't been fixed in the latest release of CubeMX (8.9) :frowning_face:

[Amel NASRI · Accepted solution]

Hi @t.decker ,

Please note that the reported issue (already tracked internally with the reference 159699) should be fixed with latest STM32CubeMX revision (6.10.0) available on st.com.

-Amel