Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 7521 invoked by uid 6000); 3 Jun 1998 17:51:54 -0000 Received: (qmail 7512 invoked from network); 3 Jun 1998 17:51:51 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 3 Jun 1998 17:51:51 -0000 Received: (qmail 26552 invoked by uid 500); 3 Jun 1998 18:06:05 -0000 Date: Wed, 3 Jun 1998 11:06:05 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: [PATCH] NET_SIZE_T on 64 bit machines In-Reply-To: <19980603174717.62267@deejai.mch.sni.de> Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="k+w/mQv8wyuph6w0" Content-ID: Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --k+w/mQv8wyuph6w0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: I should put this into the comments in conf.h or something: NET_SIZE_T exists because of shortsightedness on the POSIX committee. BSD systems used "int *" as the parameter to accept() et al. Consequently many unixes took an int * for that parameter. The POSIX committee decided that "int" was just too generic and had to be replaced with size_t almost everywhere. There's no problem with that when you're passing by value. But when you're passing by reference this creates a gross source incompatibility with existing programs. On 32-bit architectures it creates only a warning. On 64-bit architectures it creates broken code -- because "int *" is a pointer to a 64-bit quantity and "size_t *" is frequently a pointer to a 32-bit quantity. Some Unixes adopted "size_t *" for the sake of POSIX compliance. Others ignored it because it was such a broken interface. Chaos ensued. POSIX finally woke up and decided that it was wrong and created a new type socklen_t. The only useful value for socklen_t is int, and that's how everyone who has a clue implements it. It is almost always the case that NET_SIZE_T should be defined to be an int, unless the system being compiled for was created in the window of POSIX madness. Dean On Wed, 3 Jun 1998, Martin Kraemer wrote: > I noticed the problem on a 64 bit machine (with apache-1.3.0) that all log > file entries only logged accesses from addr 0.0.0.0. > > Tracking down the problem showed that the 64 bit versions of accept(), > bind() et al. need an "int *" as length parameter instead of a "size_t *". > Since this is a big endian machine (MIPS EB) the size was interpreted > as zero and the IP address of the caller was discarded. > > The patch below fixes it _for_this_machine_ (because setting the 64 bit > compilation mode sets the compiler #define __LP64__). I wonder how other > 64 bit compilers do it. > > Martin > -- > | S I E M E N S | | Siemens Nixdorf > | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG > | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany > ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request > --k+w/mQv8wyuph6w0--