Mailing List Archive

>
>
> There are 7 patch files in for_Apache_0.8.16/
>
> 44_ident.0.8.16.patch is empty.
>
> Are there any more to be considered?
>
> Can we make this the last round of patches and call the results 1.0
> and release it.
>
> Brian said he'd do the call for votes, so here are mine to get the ball
> rolling.
>
> +1 40_tz.0.8.16.patch
> +0 41_getparents.0.8.16
> +1 42_cert.no2slash.0.8
> +0 43_slashredir.0.8.16
> 44_ident.0.8.16.patch [empty !]
> +1 45_dbm_groups.0.8.16
> +1 46.dbmmanage_group.0
> +1 httpd_monitor
>
> I'll have another look at 41 and 43 should they fall short of votes.

Errr.. what happened to my patch?

>
>
> rob

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd, URL: http://www.algroup.co.uk
London, England.

>
> > > 44_ident.0.8.16.patch [empty !]
> > I've uploaded it again. Here is the header:
> >
> > From: drtr@ast.cam.ac.uk (David Robinson)
> > Subject: Fix IdentityCheck with Virtual Hosts
> > Affects: http_main.c, util.c
> > ChangeLog: Ensure that rfc931() is given a sockaddr describing the local
> > address (virtual host) that is currently in use.
> > Comments: Before this patch, rfc931() was passed 0.0.0.0 as the local address;
> > on some systems bind() managed to correctly choose the IP address
> > for the virtual host currently in use!
> >
> > David.
>
> This patch has created a warning on NetBSD regarding the declaration of
> 'struct sockaddr sa_server' in child_main and it's use as an argument
> for getsockname(). Looking through this file, we specifically cast
> many(most) of the socket addresses for the connections to sockaddr_in.
>
> The structure size is significantly bigger for sockaddr_in which
> if I understand correctly, would increase the memory usage per
> connection. Do we need to be making these casts?

Actually, they're all the same size.

>
>
> Structure comparisions follow:
>
> SunOS:
>
> struct sockaddr {
> u_short sa_family; /* address family */
> char sa_data[14]; /* up to 14 bytes of direct address */
> };
>
> struct sockaddr_in {
> short sin_family;
> u_short sin_port;
> struct in_addr sin_addr;
> char sin_zero[8];
> };
>
>
> NetBSD:
>
> struct sockaddr {
> u_char sa_len; /* total length */
> u_char sa_family; /* address family */
> char sa_data[14]; /* actually longer; address value */
> };
>
>
> struct sockaddr_in {
> u_int8_t sin_len;
> u_int8_t sin_family;
> u_int16_t sin_port;
> struct in_addr sin_addr;
> int8_t sin_zero[8];
> };
>
>

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd, URL: http://www.algroup.co.uk
London, England.

> > 44_ident.0.8.16.patch [empty !]
> I've uploaded it again. Here is the header:
>
> From: drtr@ast.cam.ac.uk (David Robinson)
> Subject: Fix IdentityCheck with Virtual Hosts
> Affects: http_main.c, util.c
> ChangeLog: Ensure that rfc931() is given a sockaddr describing the local
> address (virtual host) that is currently in use.
> Comments: Before this patch, rfc931() was passed 0.0.0.0 as the local address;
> on some systems bind() managed to correctly choose the IP address
> for the virtual host currently in use!
>
> David.

This patch has created a warning on NetBSD regarding the declaration of
'struct sockaddr sa_server' in child_main and it's use as an argument
for getsockname(). Looking through this file, we specifically cast
many(most) of the socket addresses for the connections to sockaddr_in.

The structure size is significantly bigger for sockaddr_in which
if I understand correctly, would increase the memory usage per
connection. Do we need to be making these casts?


Structure comparisions follow:

SunOS:

struct sockaddr {
u_short sa_family; /* address family */
char sa_data[14]; /* up to 14 bytes of direct address */
};

struct sockaddr_in {
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};


NetBSD:

struct sockaddr {
u_char sa_len; /* total length */
u_char sa_family; /* address family */
char sa_data[14]; /* actually longer; address value */
};


struct sockaddr_in {
u_int8_t sin_len;
u_int8_t sin_family;
u_int16_t sin_port;
struct in_addr sin_addr;
int8_t sin_zero[8];
};

>
> Structure comparisions follow:
>
> SunOS:
>
> struct sockaddr {
> u_short sa_family; /* address family */
2 bytes
> char sa_data[14]; /* up to 14 bytes of direct address */
14 bytes
> };
total=16 bytes

>
> struct sockaddr_in {
> short sin_family;
2 bytes
> u_short sin_port;
2 bytes
> struct in_addr sin_addr;
4 bytes
> char sin_zero[8];
8 bytes
> };
total=16 bytes
>
>
> NetBSD:
>
> struct sockaddr {
> u_char sa_len; /* total length */
1 byte
> u_char sa_family; /* address family */
1 byte
> char sa_data[14]; /* actually longer; address value */
14 bytes
> };
total=16 bytes
>
>
> struct sockaddr_in {
> u_int8_t sin_len;
1 byte
> u_int8_t sin_family;
1 byte
> u_int16_t sin_port;
2 bytes
> struct in_addr sin_addr;
4 bytes
> int8_t sin_zero[8];
8 bytes
> };
total=16 bytes
>
>

All the same size.

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd, URL: http://www.algroup.co.uk
London, England.

> > The structure size is significantly bigger for sockaddr_in which
> > if I understand correctly, would increase the memory usage per
> > connection. Do we need to be making these casts?
>
> Actually, they're all the same size.

Not if we can get away with only using the sockaddr struct on
systems that can. We apparently need something other than the
sa_len info as I look more at the code. Haven't figured that out
yet.

No, Randy, they *are* all the same size (16 bytes), just with varying
amounts of padding. In any case, this is far too little memory to be
seriously worried about...

rst

"He who is afraid to ask is ashamed of learning..."

Granted this is an insignificant amount of memory as RST pointed
out. sizeof struct in_addr on NetBSD is in fact 4 bytes as Ben
points out. Isn't the size of the following in_addr structure
on SunOS 16 bytes?

struct in_addr {
union {
struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
struct { u_short s_w1,s_w2; } S_un_w;
u_long S_addr;
} S_un;
#define s_addr S_un.S_addr /* should be used for all code */
#define s_host S_un.S_un_b.s_b2 /* OBSOLETE: host on imp */
#define s_net S_un.S_un_b.s_b1 /* OBSOLETE: network */
#define s_imp S_un.S_un_w.s_w2 /* OBSOLETE: imp */
#define s_impno S_un.S_un_b.s_b4 /* OBSOLETE: imp # */
#define s_lh S_un.S_un_b.s_b3 /* OBSOLETE: logical host */
};

> 44_ident.0.8.16.patch [empty !]
I've uploaded it again. Here is the header:

From: drtr@ast.cam.ac.uk (David Robinson)
Subject: Fix IdentityCheck with Virtual Hosts
Affects: http_main.c, util.c
ChangeLog: Ensure that rfc931() is given a sockaddr describing the local
address (virtual host) that is currently in use.
Comments: Before this patch, rfc931() was passed 0.0.0.0 as the local address;
on some systems bind() managed to correctly choose the IP address
for the virtual host currently in use!

David.

>
>
> "He who is afraid to ask is ashamed of learning..."
>
> Granted this is an insignificant amount of memory as RST pointed
> out. sizeof struct in_addr on NetBSD is in fact 4 bytes as Ben
> points out. Isn't the size of the following in_addr structure
> on SunOS 16 bytes?
>
> struct in_addr {
> union {
> struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
4*1 byte=4
> struct { u_short s_w1,s_w2; } S_un_w;
2*2 bytes=4
> u_long S_addr;
1*4 bytes=4
> } S_un;
total=max(4,4,4)=4 (coz this is a _union_)

> #define s_addr S_un.S_addr /* should be used for all code */
> #define s_host S_un.S_un_b.s_b2 /* OBSOLETE: host on imp */
> #define s_net S_un.S_un_b.s_b1 /* OBSOLETE: network */
> #define s_imp S_un.S_un_w.s_w2 /* OBSOLETE: imp */
> #define s_impno S_un.S_un_b.s_b4 /* OBSOLETE: imp # */
> #define s_lh S_un.S_un_b.s_b3 /* OBSOLETE: logical host */
> };
>
>

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd, URL: http://www.algroup.co.uk
London, England.

Randy wrote:
>This patch has created a warning on NetBSD regarding the declaration of
>'struct sockaddr sa_server' in child_main and it's use as an argument
>for getsockname(). Looking through this file, we specifically cast
>many(most) of the socket addresses for the connections to sockaddr_in.

That's somewhat strange; I copied the call _exactly_ from the get_portnum()
routine in util.c; presumably _before_ this patch you got a warning
compiling util.c under NetBSD?

What is the prototype for getsockname() under NetBSD?

David.

> Randy wrote:
> >This patch has created a warning on NetBSD regarding the declaration of
> >'struct sockaddr sa_server' in child_main and it's use as an argument
> >for getsockname(). Looking through this file, we specifically cast
> >many(most) of the socket addresses for the connections to sockaddr_in.
>
> That's somewhat strange; I copied the call _exactly_ from the get_portnum()
> routine in util.c; presumably _before_ this patch you got a warning
> compiling util.c under NetBSD?

No warnings in any files prior to this patch.

> What is the prototype for getsockname() under NetBSD?
>
> David.

int
getsockname(int s, struct sockaddr *name, int *namelen)


Looking at get_portnum()...it's commented out for starters.
Secondly, it sets the second parameter to sockaddr which it
should be. The warning is caused by using sockaddr_in.