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

[Stephan Trebels]

Personally I agree, that sa_len is redundant, but lots of
BSD4[34]-derivatives have the sa_len field.  Portable code needs to take
this into account if DEC UNIX, or AIX, or *BSD, or the Hurd is
targetted.  Solaris8/Linux don't have it of course. There must be an
autoconf test for the field in struct sockaddr and then the code needs
to be #ifdef'd.  Ugly, but neccessary.

As the vast majority of glibc/i386 users (Linux) are using the
BSD42/SYSV variant of struct sockaddr, it feels wrong to break SOURCE
compatibility in glibc/i386 when writing NEW software like the Hurd,
where it can easily be changed, still.  

Unless the glibc/i386 maintainers can be convinced to use a different
struct sockaddr in Linux breaking binary compatibility there, the Hurd
should use the same struct sockaddr as Linux in my personal opinion as
an innocent bystander.  

Anyway, should there be any value in sa_len (no clue, perhaps when
passing a struct sockaddr to your own function, so you don't know the
length?), perhaps Linux will eventually add a sa_len field, or glibc can
have it's own kernel-independent struct sockaddr on the API layer. I
don't quite understand, why glibc needs to use the same one as the
underlying kernel, except for simplicity of glibc code.

My $0.02, Stephan

On Mon, 2003-04-28 at 09:07, Niels Möller wrote:
> 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
> 
> 
> _______________________________________________
> Bug-hurd mailing list
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd
-- 
        Stephan Trebels <stephan@ncube.de>   Consultant
company: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
phone: cell:+49 172 8433111  office:+49 89 1498930  fax:+49 89 14989350