sizeof(socklen_t) with native_sim/64: should it be 4 or 8?

[mkaranki]

Hi,

I've been debugging crash caused by net_getaddrinfo_addr_str returning address where data is not ok. I have solved that the same program sees different sizes of socklen_t:

invoke_query_callback (status=-100, info=0x7fffc3dff7f0, pending_query=0x71d950 <dns_default_ctx+432>)
    at zephyr/subsys/net/lib/dns/resolve.c:604
604     }
(gdb) p *(struct zsock_addrinfo *) 0x7fffac0037e0
$91 = {ai_next = 0x0, ai_flags = 0, ai_family = 1, ai_socktype = 1, ai_protocol = 6, ai_eflags = 0, ai_addrlen = 0, ai_addr = 0x8, 
  ai_canonname = 0x7fffac003818 "\001", _ai_addr = {sa_family = 14368, data = "\000\254\377\177\000"}, 
  _ai_canonname = "\001\000\"\263\254\030\250\342", '\000' <repeats 12 times>}
(gdb) ptype /o struct zsock_addrinfo
/* offset      |    size */  type = struct zsock_addrinfo {
/*      0      |       8 */    struct zsock_addrinfo *ai_next;
/*      8      |       4 */    int ai_flags;
/*     12      |       4 */    int ai_family;
/*     16      |       4 */    int ai_socktype;
/*     20      |       4 */    int ai_protocol;
/*     24      |       4 */    int ai_eflags;
/*     28      |       4 */    socklen_t ai_addrlen;
/*     32      |       8 */    struct sockaddr *ai_addr;
/*     40      |       8 */    char *ai_canonname;
/*     48      |       8 */    struct sockaddr {
/*     48      |       2 */        sa_family_t sa_family;
/*     50      |       6 */        char data[6];

                                   /* total size (bytes):    8 */
                               } _ai_addr;
/*     56      |      21 */    char _ai_canonname[21];
/* XXX  3-byte padding   */

                               /* total size (bytes):   80 */
                             }
(gdb) ptype /o zsock_addrinfo
/* offset      |    size */  type = struct zsock_addrinfo {
/*      0      |       8 */    struct zsock_addrinfo *ai_next;
/*      8      |       4 */    int ai_flags;
/*     12      |       4 */    int ai_family;
/*     16      |       4 */    int ai_socktype;
/*     20      |       4 */    int ai_protocol;
/*     24      |       4 */    int ai_eflags;
/*     28      |       4 */    socklen_t ai_addrlen;
/*     32      |       8 */    struct sockaddr *ai_addr;
/*     40      |       8 */    char *ai_canonname;
/*     48      |       8 */    struct sockaddr {
/*     48      |       2 */        sa_family_t sa_family;
/*     50      |       6 */        char data[6];

                                   /* total size (bytes):    8 */
                               } _ai_addr;
/*     56      |      21 */    char _ai_canonname[21];
/* XXX  3-byte padding   */

                               /* total size (bytes):   80 */
                             }

Note 2 things:

1. ai_addr member has value that actually belongs to ai_addrlen, looks like there's some offset.
2. socklen_t is 4 bytes.

However when debugging inside dns_resolve_cb on subsys/net/lib/sockets/getaddrinfo.c, I can see the struct differently after returning there:

(gdb) ptype /o *ai
/* offset      |    size */  type = struct zsock_addrinfo {
/*      0      |       8 */    struct zsock_addrinfo *ai_next;
/*      8      |       4 */    int ai_flags;
/*     12      |       4 */    int ai_family;
/*     16      |       4 */    int ai_socktype;
/*     20      |       4 */    int ai_protocol;
/*     24      |       4 */    int ai_eflags;
/* XXX  4-byte hole      */
/*     32      |       8 */    socklen_t ai_addrlen;
/*     40      |       8 */    struct sockaddr *ai_addr;
/*     48      |       8 */    char *ai_canonname;
/*     56      |       8 */    struct sockaddr {
/*     56      |       2 */        sa_family_t sa_family;
/*     58      |       6 */        char data[6];

                                   /* total size (bytes):    8 */
                               } _ai_addr;
/*     64      |      21 */    char _ai_canonname[21];
/* XXX  3-byte padding   */

                               /* total size (bytes):   88 */
                             }

There, socklen_t is 8 bytes and in addition, there's 4 byte alignment hole. So the struct is seen 8 bytes longer. That would explain why there seems to be that offset: due to differently seen sizeof(socklen_t).

Unfortunately my application is seeing the broken data. But, I don't have too much of a clue how this should work. net_ip is setting socklen_t when __socklen_t_defined is not set:

zephyr/include/zephyr/net/net_ip.h

Lines 170 to 174 in 5ad9494

	/** Length of a socket address */
	#ifndef __socklen_t_defined
	typedef size_t socklen_t;
	#define __socklen_t_defined
	#endif

... and sizeof(size_t) is 8 on 64 bit platforms.

But system headers shipped with Ubuntu are using uint32:

x86_64-linux-gnu/bits/types.h:__STD_TYPE __U32_TYPE __socklen_t;

bits/types.h is included by many standard headers. Commit 6c934ab / PR #57196 has been dealing with this issue, but seems to only hide it? Should something be forcing __socklen_t_defined, or how?

If I change socklen_t typedef from size_t to uint32_t I see my application is fine, and so it is also with 32 bit native_sim. In general, 4 bytes is more than enough to store the length of socket address?

How do you see this should work? It's bit hard to create standalone reproducible example, but I can try that later if it is helpful. I am working on top of Zephyr 3.7.

(Pinging @rlubos and @jukkar maybe as I think this is area of your expertise if it is appropriate to do that)

[mkaranki]

POSIX 2024 explains socklen_t type:

B.2.10.6 Socket Types
The type socklen_t was invented to cover the range of implementations seen in the field. The intent of socklen_t is to be the type for all lengths that are naturally bounded in size; that is, that they are the length of a buffer which cannot sensibly become of massive size: network addresses, host names, string representations of these, ancillary data, control messages, and socket options are examples. Truly boundless sizes are represented by size_t as in read(), write(), and so on.

All socklen_t types were originally (in BSD UNIX) of type int. During the development of POSIX.1-2024, it was decided to change all buffer lengths to size_t, which appears at face value to make sense. When dual mode 32/64-bit systems came along, this choice unnecessarily complicated system interfaces because size_t (with long) was a different size under ILP32 and LP64 models. Reverting to int would have happened except that some implementations had already shipped 64-bit-only interfaces. The compromise was a type which could be defined to be any size by the implementation: socklen_t.

[jukkar]

It looks like we should define it as 32-bits in zephyr to make sure things work properly in native_sim_64. The size of 4 bytes is certainly enough to store the information.
cc: @cfriedt as a Posix guru, do you have any opinion about this?

[cfriedt]

Rather than using socklen_t, it might just make more sense to use uint32_t. That way, no POSIX leakage occurs.

In any case, it seems to be 4 bytes in 32-bit and 64-bit GNU systems.

cfriedt@ubuntu:/tmp$ gcc -m32 -o /tmp/blah /tmp/blah.c
cfriedt@ubuntu:/tmp$ /tmp/blah 
sizeof(socklen_t): 4
cfriedt@ubuntu:/tmp$ gcc -m64 -o /tmp/blah /tmp/blah.c
cfriedt@ubuntu:/tmp$ /tmp/blah 
sizeof(socklen_t): 4

In POSIX, we could also use a BUILD_ASSERT() to ensure that the sizeof of socklen_t is the same as that of a uint32_t.

[jukkar]

Thanks @cfriedt for insight info. I am not sure we can get rid of socklen_t but I can prepare a PR that changes the type to uint32_t

[jukkar]

Fixed by #96903