sa_len (Was Re: Bug#187391: bug found (in libc))

[Niels Möller]

GOTO Masanori <gotom@debian.or.jp> writes:

> BTW, Roland, could you plan to add sun_len into sockaddr_un on Hurd?
> It's not senseless modification, I think.

Perhaps I'm confused, but I thought the current state is that sun_len
*is* in there.

Sorry if I'm getting a little off-topic now, but could someone please
explain the sense of sa_len? It would be an improvement of the sockets
API to have struct sockaddr include the length of the actual address,
*and* at the same time *delete* the third argument to

       int connect(int sockfd, const struct sockaddr *serv_addr,
                   socklen_t addrlen);

       int bind(int sockfd, struct sockaddr *my_addr,
                socklen_t addrlen);

But we can't do that (for compatibility with the standard socket API).
And then sa_len looks very redundant, it's just one more annoying
difference between systems to keep track of.

Portable programs can't take any advantage of it anyway. Ok, now
portable code isn't everything, code written specifically for GNU or
BSD could use sa_len and perhaps gain a little simplicity. And in
principle I have nothing against GNU-specific extensions to various
more or less broken standard API:s. But I think one shouldn't do that
gratiously; such extentions should be made only where there is some
solid value of the extension (for example, I'm a little annoyed that
the gcc folks have deprecated __FUNCTION__ in favor of the less useful
but standard __func__).

But I fail to see the solid value of sa_len; it just seems too
redundant to pass this test.

Regards,
/Niels