[fpc-devel]possible bug in sockets.pp

[Marco van de Voort]

[ Charset ISO-8859-1 unsupported, converting... ]
> From: "Jonas Maebe" <jonas at zeus.rug.ac.be>
> Subject: Re: [fpc-devel]possible bug in sockets.pp
> 
> > On 2 Nov 2001 Thomas.Hergenhahn at nexans.com wrote:
> >
> > > When I tried to open a socket in the unix domain bind(Sock, Addr,
> > > SizeOf(Addr)) returned the error "invalid argument", but I could not
> > > find what was wrong with my code. When I changed the definition
> > > of TUnixSockAddr in sockets.pp from:
> > >
> > > type
> > >   TUnixSockAddr = packed Record
> > >     family:word; { was byte, fixed }
> > >     path:array[0..108] of char;
> > >     end;
> >
> > That's not correct, in the C headers family is an "unsigned short", which
> > is the same as a byte in Pascal.
> 
> No, "unsigned short" equals the Pascal "Word" type (usually). Pascal "Byte"
> equals "unsigned char".
> 
> >From socket.h:
> 
> #define UNIX_PATH_MAX   108
> 
> struct sockaddr_un {
>         sa_family_t     sun_family;     /* AF_UNIX */
>         char    sun_path[UNIX_PATH_MAX];        /* pathname */
> };
> 
> With the current implementation the array sizes would be different, because
> sizeof(array[0..108]) is 109 bytes while sizeof(char[108]) = 108.
> 
> Even if sa_family_t were "unsigned char", I 'd assume that the structure
> members are automatically padded to begin at least at even addresses, so
> a padding byte would be required.

OP also uses packed record, not {$PACKRECORDS C}

Since most fields seems to be word align, that shouldn't matter though.