[lwip-users] errno is not set in sockets.c

[Mason]

Hello,

I am porting libcurl on top of lwip on a POSIX platform.
(libcurl uses the BSD sockets API, and non-blocking sockets.)

Calling connect on a non-blocking socket is supposed to
return EINPROGRESS in errno, but in my port, errno is
not set.

Looking at sockets.c, the relevant code is:

#ifdef ERRNO
#ifndef set_errno
#define set_errno(err) errno = (err)
#endif
#else /* ERRNO */
#define set_errno(err)
#endif /* ERRNO */

#define sock_set_errno(sk, e) do { \
sk->err = (e); \
set_errno(sk->err); \
} while (0)

If ERRNO is undefined, set_errno is a NOP, thus errno is never set.

What is the semantics / meaning of the ERRNO macro?

It is only checked in sockets.c
(and it is not set in my platform's system headers)
$ grep -rn "[^_]ERRNO" src
src/api/sockets.c:161:#ifdef ERRNO
src/api/sockets.c:165:#else /* ERRNO */
src/api/sockets.c:167:#endif /* ERRNO */

The unix port leaves ERRNO undefined, which means errno is never
set in the unix port (?!)

I'm familiar with the LWIP_PROVIDE_ERRNO macro, which I did NOT
define because I've included my platform's errno.h in cc.h

I propose deleting this ERRNO stuff:

--- sockets.c.orig 2012-02-23 10:57:12.796875000 +0100
+++ sockets.c 2012-03-20 10:50:40.375000000 +0100
@@ -158,13 +158,9 @@
((unsigned)(-(err)) < ERR_TO_ERRNO_TABLE_SIZE ? \
err_to_errno_table[-(err)] : EIO)

-#ifdef ERRNO
#ifndef set_errno
#define set_errno(err) errno = (err)
#endif
-#else /* ERRNO */
-#define set_errno(err)
-#endif /* ERRNO */

#define sock_set_errno(sk, e) do { \
sk->err = (e); \

(If someone wants his port to leave errno intact, they should
define set_errno to a NOP in his port's cc.h)

Did I miss something obvious, or something not so obvious?

--
Regards.

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Kieran Mansley]

On 20 Mar 2012, at 09:53, Mason wrote:

> Looking at sockets.c, the relevant code is:
>
> #ifdef ERRNO
> #ifndef set_errno
> #define set_errno(err) errno = (err)
> #endif
> #else /* ERRNO */
> #define set_errno(err)
> #endif /* ERRNO */

I suspect that it might be something relevant to Windows ports. I can't see a problem with the change you suggest, but I'd like to understand what this was for in the first place as I'm cautious when it comes to things that require changes to the ports - we need to have a good reason for them. Is there anything stopping you defining ERRNO in your port or compiler, as I think that will yield the code you need.

Kieran

[gold...@gmx.de]

Kieran Mansley wrote:
> On 20 Mar 2012, at 09:53, Mason wrote:
>
>> Looking at sockets.c, the relevant code is:
>>
>> #ifdef ERRNO
>> #ifndef set_errno
>> #define set_errno(err) errno = (err)
>> #endif
>> #else /* ERRNO */
>> #define set_errno(err)
>> #endif /* ERRNO */
> I suspect that it might be something relevant to Windows ports. I can't see a problem with the change you suggest, but I'd like to understand what this was for in the first place as I'm cautious when it comes to things that require changes to the ports - we need to have a good reason for them.

I don't think it's a Windows port thing: it's not defined in the windows
port plus it compiles correctly with or without ERRNO being defined.
It's odd though that it's not defined: I have written code (in
contrib/apps/socket_examples) that uses 'errno' to assert things (and
successfully used it for testing nonblocking sockets) but it obviously
doesn't run without that define... :-/

I do know that I've just added the '#ifndef set_errno' 2 years ago, so
the '#ifdef ERRNO' was probably the only way to *not* use 'errno' before
that.

Personally, I think it's correct that we do not change 'errno' without
explicitly enabling it: we don't want to mess with C library code that
uses 'errno' by default.

Simon

[Mason]

Simon wrote:

> Personally, I think it's correct that we do not change 'errno' without
> explicitly enabling it: we don't want to mess with C library code that
> uses 'errno' by default.

I cannot stress how strongly I disagree on this point.

I will take the discussion to lwip-dev by filing a bug.

NB: I think lwip is a great project, but let's face it, the
documentation is severely lacking. I wasted /hours/ tracking
down libcurl's failure to connect in non-blocking mode, only
to stumble upon this piddly, undocumented macro.

<sigh>

--
Regards.