Q: D_SUN_LEN , dpi programs and socket programming
The bookmarks and cookies dpis define D_SUN_LEN but don't use it. D_SUN_LEN is used elsewhere by dillo (when calling connect()) and dpid (when calling bind()), but all the dpi programs call accept() with sizeof(struct sockaddr_un) instead of D_SUN_LEN(address). Shouldn't we delete the definition of D_SUN_LEN from the dpi programs since they don't use it? Or maybe they should use it? Which? Regards, Jeremy Henty
On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote:
The bookmarks and cookies dpis define D_SUN_LEN but don't use it. D_SUN_LEN is used elsewhere by dillo (when calling connect()) and dpid (when calling bind()), but all the dpi programs call accept() with sizeof(struct sockaddr_un) instead of D_SUN_LEN(address). Shouldn't we delete the definition of D_SUN_LEN from the dpi programs since they don't use it? Or maybe they should use it? Which?
Given that IO/dpi.c uses both without (reported) problems, it'd be good to have everyone use D_SUN_LEN. That way we can filed test easily by changing the macro definition. Maybe there're systems where this still matters. -- Cheers Jorge.-
On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote:
Shouldn't we delete the definition of D_SUN_LEN from the dpi programs since they don't use it? Or maybe they should use it? Which?
Given that IO/dpi.c uses both without (reported) problems, it'd be good to have everyone use D_SUN_LEN.
Actually, I think I was confused. The accept() man page says The addrlen argument is a value-result argument: it should initially contain the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. So passing sizeof(struct sockarr_un) to accept() is correct. Indeed, passing D_SUN_LUN(&address) could be disastrous because address is uninitialised (since we expect accept() to fill it in). So I think the code is correct and we should just remove the unused D_SUN_LEN definitions. Patch attached. Jeremy Henty
On Wed, Oct 29, 2008 at 08:46:28PM +0000, Jeremy Henty wrote:
On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote:
Shouldn't we delete the definition of D_SUN_LEN from the dpi programs since they don't use it? Or maybe they should use it? Which?
Given that IO/dpi.c uses both without (reported) problems, it'd be good to have everyone use D_SUN_LEN.
Actually, I think I was confused. The accept() man page says
The addrlen argument is a value-result argument: it should initially contain the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned.
So passing sizeof(struct sockarr_un) to accept() is correct. Indeed, passing D_SUN_LUN(&address) could be disastrous because address is uninitialised (since we expect accept() to fill it in). So I think the code is correct and we should just remove the unused D_SUN_LEN definitions. Patch attached.
OK, but I was talking about connect(). -- Cheers Jorge.-
On Thu, Oct 30, 2008 at 09:29:55AM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 29, 2008 at 08:46:28PM +0000, Jeremy Henty wrote:
On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote:
Given that IO/dpi.c uses both without (reported) problems, it'd be good to have everyone use D_SUN_LEN.
So I think the code is correct and we should just remove the unused D_SUN_LEN definitions. Patch attached.
OK, but I was talking about connect().
Patch attached. Also, all uses of bind() already use D_SUN_LEN. Incidentally, does anyone know why there is no analog of D_SUN_LEN for connect()-ing to a struct sockaddr_in? The struct has a sin_path member just as struct sockaddr_un has a sun_path , so what is the difference? (I'm new to the C socket API.) Regards, Jeremy Henty
participants (2)
-
jcid＠dillo.org -
onepoint＠starurchin.org