Re: Stats Collector Error 7.4beta1 and 7.4beta2

From: <andrew(at)dunslane(dot)net>
To: <JanWieck(at)yahoo(dot)com>
Cc: <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <Q(at)ping(dot)be>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <matthew(at)zeut(dot)net>, <akavan(at)cox(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Stats Collector Error 7.4beta1 and 7.4beta2
Date: 2003-09-06 01:09:19
Message-ID: 2556.24.211.141.25.1062810559.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


This analysis makes sense - I think using memcmp is clearly wrong here.

cheers

andrew

Jan Wieck said:
> On a second thought,
>
> I still believe that this is just garbage in the padding bytes after
> the IPV4 address. The code currently bind()'s and connect()'s
> explicitly to an AF_INET address. So all we ever should see is
> something from and AF_INET address. Everything else in the sin_family
> has to be discarded. I do not think it is allowed to bind() and
> connect() to an IPV4 address and then get anything other than an IPV4
> address back from the system. If that is the case, the whole idea is
> broken.
>
> An AF_INET address now has only two relevant fields, the sin_port and
> sin_addr. If they are the same, everything is fine. So the correct
> check would be that 1. fromlen > sizeof(sin_family), 2. sin_family ==
> AF_INET, 3. sin_port and sin_addr identical.
>
> After reading Kurt's quoting of the SUS manpage I have to agree with
> Tom in that we cannot skip the check entirely. It says it limits for
> recv() but we are using recvfrom() ... there might be a little
> difference on that platform ...
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-09-06 02:26:19 Re: Stats Collector Error 7.4beta1 and 7.4beta2
Previous Message Tom Lane 2003-09-05 23:55:44 Re: Notices for redundant operations