Re: OSF build fixed
От | Kurt Roeckx |
---|---|
Тема | Re: OSF build fixed |
Дата | |
Msg-id | 20030715203958.GA6812@ping.be обсуждение исходный текст |
Ответ на | Re: OSF build fixed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: OSF build fixed
|
Список | pgsql-hackers |
On Tue, Jul 15, 2003 at 04:28:49PM -0400, Tom Lane wrote: > Kurt Roeckx <Q@ping.be> writes: > > On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: > >> Applied (along with some further hacking to make the struct padding > >> logic more robust). > > > I'm not sure what you did exactly, or why you think it's better. > > But it seems you removed the "6 byte pad", between the > > ss_family and the __ss_align, and I have no idea why. > > If the pad is needed, it'll be there. Making it explicit doesn't > buy anything. > > > Note that I didn't just make that structure up, other people did. > > It's for instance like that in the RFC and in SUS v3. > > I wouldn't have touched it if the code actually worked, but it does not > work as intended once you stick in the #ifdef SALEN thingy. The padding > computation was not accounting for that. To make it work correctly > we'd have had to add an additional explicit pad field ... which, if > sa_family_t happened to be "char" and not "short", would be a > zero-element array, resulting in a compile failure. BSD 4.3 didn't have an sa_len, while 4.4 did. in BSD 4.3 sa_family was a short, in 4.4 it was split up in 2 chars. Note that the RFC has 2 examples, one without sa_len, an other with sa_len. Kurt
В списке pgsql-hackers по дате отправления: