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;
to:
type
  TUnixSockAddr = packed Record
    family:word; { was byte, fixed }
    path:array[0..107] of char;
    end;

bind works fine.

That's not correct, in the C headers family is an "unsigned short", which is the same as a byte in Pascal.

PS: some virus scanner from another provider "replied" to your message stating that your computer is infected with a virus. There was indeed an attachment added to your message with the name "winmail.dat", so please desinfect your computer as soon as possible.

Jonas

From: "Jonas Maebe"
Subject: Re: [fpc-devel]possible bug in sockets.pp

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.

Regards,
Thomas

[ Charset ISO-8859-1 unsupported, converting... ]

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

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

which

> is the same as a byte in Pascal. No, "unsigned short" equals the Pascal "Word" type (usually). Pascal

"Byte"

equals "unsigned char".

Well forget above paragraph of mine, it's wrong. "Unsigned char" doesn't exist and I'm starting to mix up everything. Nevertheless sizeof(unsigned short) gives 2 with VC++. [Not that I'd take VC++ for compliance testing of anything but it is a point].

Probably it's the alignment stuff.

Regards,
Thomas

Oops, you're right of course! I'll also adapt the padding array so that it becomes the correct size.

Jonas

From: "Thomas Schatzl"

> > That's not correct, in the C headers family is an "unsigned short", which > > is the same as a byte in Pascal.

Nope!!!

of

anything but it is a point].

Well, unsigned short is in allmost all implementations 2 bytes (i.e. 16bit), this is true in VC as well as GCC as well as Watcom as well ac DEC C as well as Sun Pro C as well as Intel C as well as Borland C as well as... The only what C definition says is that plain int must be no longer than long int and no shorter than short int. De facto standard is 16bit for short and 32bit for long, plain is usually but not allways 32bit (in 16bit architectures it is rather 16bit) -- I dont know alny compiler making it differently (probably Deep Blue C from 8-bit Atari was different, but it was not fully fledged C, anyway)

As for unsigned char -- yes, it exists. There are all unsigned char, signed char and just char (which is unknown if it is signed or not -- standard says it could be anything).

rgds
Sebastian Kaliszewski