Improved integration with the lwip library by MAntoniak · Pull Request #20441 · curl/curl

MAntoniak · 2026-01-26T15:35:14Z

Using the lwip_* function family.
Use of the inet_ntop and lwip_inet_pton functions.
I did not change references to functions if they appeared inside the linux or USE_WINSOCK definitions.

vszakats · 2026-01-26T15:52:50Z

lib/curl_setup.h

+#ifdef HAVE_GETHOSTBYNAME_R_6
+#define CURL_GETHOSTBYNAME_R lwip_gethostbyname_r
+#endif
+#ifdef HAVE_GETPEERNAME
+#define CURL_GETPEERNAME lwip_getpeername
+#endif
+#ifdef HAVE_GETSOCKNAME
+#define CURL_GETSOCKNAME lwip_getsockname
+#endif


In what cases are these these 3 functions unavailable when
USE_LWIPSOCK is defined? Why guard them like this?

You're right, it's unnecessary. I can update it, but I'm waiting for a decision on the future of this PR.

vszakats · 2026-01-26T15:52:57Z

lib/curlx/inet_ntop.h

                    (curl_socklen_t)(size))
+#elif defined(USE_LWIPSOCK)
+#define curlx_inet_ntop(af,addr,buf,size)                               \
+        lwip_inet_ntop(af, addr, buf, (curl_socklen_t)(size))


Suggested change

lwip_inet_ntop(af, addr, buf, (curl_socklen_t)(size))

lwip_inet_ntop(af, addr, buf, (curl_socklen_t)(size))

(minor indent nit)

vszakats · 2026-01-26T16:40:45Z

lib/curl_setup.h

+#define CURL_LISTEN listen
+#define CURL_SELECT select
+#define CURL_SETSOCKOPT setsockopt
+#endif


Wouldn't the new macros need to be used in test code too,
for consistency, and to allow building (and running) tests
with lwip enabled?

edit: also in src.

dfandrich · 2026-01-26T19:40:01Z

It seems strange that lwip provides a POSIX-like API but with different identifiers. Does it not have a compatibility mode that provides the standard names? Does it really expect every network application to adapt to its oddball names?

dfandrich · 2026-01-26T19:42:51Z

The INSTALL.md file actually mentions lwip and talks about "BSD-style lwIP TCP/IP stack support" and that curl has been tested with lwip 1.4.0. Have you looked at that section of the document and make sure to abide by the prerequisites?

bagder · 2026-01-26T22:07:55Z

It seems strange that lwip provides a POSIX-like API but with different identifiers. Does it not have a compatibility mode that provides the standard names? Does it really expect every network application to adapt to its oddball names?

And if they need oddball names, why not define them the other way around? In this style:

#ifdef USE_LWIPSOCK
#define setsockopt() lwip_.... ()
...
#endif

vszakats · 2026-01-27T01:37:23Z

Looking at lwip sources, it offers a macro to enable defining standard
functions, mapping them to lwip-prefixed one automatically: LWIP_COMPAT_SOCKETS.
https://github.com/lwip-tcpip/lwip/blob/4599f551dead9eac233b91c0b9ee5879f5d0620a/src/include/lwip/sockets.h#L551-L593
(it goes back to the initial commit from year 2002.)

It also offers POSIX-compatible headers via:
https://github.com/lwip-tcpip/lwip/tree/master/src/include/compat
they were added in 2012 via lwip-tcpip/lwip@d910786, released in v2.0.

I wonder if there is a reason not using them.

MAntoniak · 2026-01-27T08:54:37Z

The main reason for these changes is the use of the lwip library without defining LWIP_COMPAT_SOCKETS. I was inspired by what has already been done for the close and fcntl functions in the curl_setup_once.h file.

We use the curl and lwip libraries in the embedded system. Our main code is written in C++. The entire project is built by Visual Studio and gcc. When defining LWIP_COMPAT_SOCKETS, it is not possible to build the project because we use these function/method names in many places, even though they are often private class methods or functions written in a different namespace. Macros will always win over a method name because it runs before compilation. For this reason, we decided not to define LWIP_COMPAT_SOCKETS.

vszakats · 2026-01-27T12:35:57Z

The main reason for these changes is the use of the lwip library without defining LWIP_COMPAT_SOCKETS. I was inspired by what has already been done for the close and fcntl functions in the curl_setup_once.h file.

We use the curl and lwip libraries in the embedded system. Our main code is written in C++. The entire project is built by Visual Studio and gcc. When defining LWIP_COMPAT_SOCKETS, it is not possible to build the project because we use these function/method names in many places, even though they are often private class methods or functions written in a different namespace. Macros will always win over a method name because it runs before compilation. For this reason, we decided not to define LWIP_COMPAT_SOCKETS.

Past cases required strong reasons, since they impact working with
the code in significant ways. (also src and tests.)

I'd expect LWIP_COMPAT_SOCKETS to only affect the curl build itself,
which is a distinct one, producing the library and accessed via it and the
public headers. Do I understand correctly, that you build libcurl sources
as part of another project without such separation?

MAntoniak · 2026-01-27T13:29:26Z

Do I understand correctly, that you build libcurl sources as part of another project without such separation?

Yes, I am building the project as a single piece to be programmed on a microcontroller.

dfandrich · 2026-01-27T17:21:42Z

Yes, I am building the project as a single piece to be programmed on a microcontroller.

Why not enable lwip BSD compatibility only when building the libcurl portion of the project? Any build system that is capable of building libcurl would be capable of building different parts independently. I'm still not sure exactly what the problem is.

MAntoniak · 2026-01-27T18:13:11Z

Yes, I am building the project as a single piece to be programmed on a microcontroller.
Why not enable lwip BSD compatibility only when building the libcurl portion of the project? Any build system that is capable of building libcurl would be capable of building different parts independently. I'm still not sure exactly what the problem is.

I also use the lwip library in other parts of project, such as the TCP server/client, UDP server, protocol SNTP etc. The lwip library is heavily integrated into the project and it is not easy to separate lwip from the rest.

dfandrich · 2026-01-27T18:20:02Z

But, if the compatibility layer is just a set of macros, that could be enabled only when compiling libcurl, right?

MAntoniak · 2026-01-27T18:53:41Z

But, if the compatibility layer is just a set of macros, that could be enabled only when compiling libcurl, right?

I'm not sure if I understand correctly, but this could work if the macro set were defined in this file. However, these macros are defined in lwip/sockets.h.

dfandrich · 2026-01-27T19:24:06Z

I'm not sure if I understand correctly, but this could work if the macro set were defined in this file. However, these macros are defined in lwip/sockets.h.

That file is included in curl_setup.h, so it should be available to libcurl. If that's the file that's causing issue in the rest of the application, just make sure it's not being included there. Or, if the problem is macros within that file, make sure that they're turned off in the rest of your application. I don't know how you're building your application, but I'm pretty sure you can make this to work without touching curl. We don't want to add hacks to curl for particular application since it works fine already (apparently) with lwip.

Also: - checksrc: ban `send` and `recv`, as documented in `CODE_STYLE.md`. Follow-up to 9a26633 #17572 Ref: a585cc3 #20097 Ref: #20441 Closes #20459

vszakats · 2026-01-28T16:48:49Z

Agreed this is better solved locally on the build side, by separating
components or build settings.

I tried building curl with lwIP, and found a number of issues. Also
found that existing few lwip_-prefixed API uses don't seem to be
necessary with the lwIP compat macro enabled (which is the default).
(also why prefix these 4 APIs in particular?)

Further, lwip_init() is only called on Windows, and some code in
setup-win32.h, and INSTALL.md suggest lwIP support was
implemented specifically for Windows? Yet, configuration in
setup-win32.h is incomplete, _WIN32 and USE_WINSOCK
uses mixed up, CURL_TYPEOF_CURL_SOCKLEN_T size wrong.
It made me wonder how it may compile in a real-world setting?
INSTALL.md mentions v1.4.0 (2011-05-06) which was prior to
POSIX-compatible headers. Requiring v2.0.0 (2016-11-10) may help
using lwIP transparently as a BSD-style socket API on non-BSD.

Also lwIP support is missing from both cmake and autotools.

[ Finally, lwIP itself did not produce a linkable library with mingw-w64,
even after getting around some of the build issues. Maybe its Windows
support is limited to MSVC, I'm not sure. It feels not really made for
"general consumption". ]

I merged a couple of related fixes via #20455 and #20459.

MAntoniak · 2026-02-03T08:53:48Z

I have decided to close this PR. I am unable to address this issue at this time. Thank you for all your advice.

Improved integration with the lwip library

0712158

vszakats reviewed Jan 26, 2026

View reviewed changes

vszakats mentioned this pull request Jan 28, 2026

build: replace send/recv with swrite/sread where missing #20459

Closed

vszakats added a commit that referenced this pull request Jan 28, 2026

build: replace send/recv with swrite/sread where missing

483f429

Also: - checksrc: ban `send` and `recv`, as documented in `CODE_STYLE.md`. Follow-up to 9a26633 #17572 Ref: a585cc3 #20097 Ref: #20441 Closes #20459

MAntoniak closed this Feb 3, 2026

MAntoniak deleted the lwip branch February 4, 2026 15:19

	lwip_inet_ntop(af, addr, buf, (curl_socklen_t)(size))
	lwip_inet_ntop(af, addr, buf, (curl_socklen_t)(size))

Uh oh!

Conversation

MAntoniak commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vszakats Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

MAntoniak Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

vszakats Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vszakats Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfandrich commented Jan 26, 2026

Uh oh!

dfandrich commented Jan 26, 2026

Uh oh!

bagder commented Jan 26, 2026

Uh oh!

vszakats commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MAntoniak commented Jan 27, 2026

Uh oh!

vszakats commented Jan 27, 2026

Uh oh!

MAntoniak commented Jan 27, 2026

Uh oh!

dfandrich commented Jan 27, 2026 via email

Uh oh!

MAntoniak commented Jan 27, 2026

Uh oh!

dfandrich commented Jan 27, 2026 via email

Uh oh!

MAntoniak commented Jan 27, 2026

Uh oh!

dfandrich commented Jan 27, 2026 via email

Uh oh!

vszakats commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MAntoniak commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

MAntoniak commented Jan 26, 2026 •

edited

Loading

vszakats Jan 26, 2026 •

edited

Loading

vszakats commented Jan 27, 2026 •

edited

Loading

vszakats commented Jan 28, 2026 •

edited

Loading