Re: Stats Collector Error 7.4beta1 and 7.4beta2
От | |
---|---|
Тема | Re: Stats Collector Error 7.4beta1 and 7.4beta2 |
Дата | |
Msg-id | 2556.24.211.141.25.1062810559.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: Stats Collector Error 7.4beta1 and 7.4beta2 (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Stats Collector Error 7.4beta1 and 7.4beta2
|
Список | 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 ... > >
В списке pgsql-hackers по дате отправления: