From dev-return-10955-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Jan 29 00:45:45 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 28575 invoked from network); 29 Jan 2004 00:45:45 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 29 Jan 2004 00:45:45 -0000 Received: (qmail 89742 invoked by uid 500); 29 Jan 2004 00:45:25 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 89697 invoked by uid 500); 29 Jan 2004 00:45:24 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 89644 invoked from network); 29 Jan 2004 00:45:24 -0000 Date: Wed, 28 Jan 2004 16:45:27 -0800 From: Ben Reser To: Greg Hudson , dev@apr.apache.org Subject: Re: Solving the off_t problem in APR 1.0 Message-ID: <20040129004526.GO25614@occipital.brain.org> References: <20040123121844.GB2590@manyfish.co.uk> <200401222310.i0MNAID5020903@error-messages.mit.edu> <200401231745.i0NHjhks021345@error-messages.mit.edu> <20040127104925.GC19669@redhat.com> <1075217539.16682.183.camel@error-messages.mit.edu> <20040128033325.GJ25614@occipital.brain.org> <20040128223441.GA17182@manyfish.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040128223441.GA17182@manyfish.co.uk> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.39 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Wed, Jan 28, 2004 at 10:34:41PM +0000, Joe Orton wrote: > One possible minor issue with this patch: > > if a C++ library based on APR uses apr_off_t in its API, I believe that > changing apr_off_t from a long to an int changes the ABI of that > library, because of the name mangling stuff. > > I don't know of any C++ libraries based on APR, and fixing the > incompatibility with Perl is probably far more important anyway. Ignore > it? D'oh, I'm tempted to say ignore it. But I know rapidsvn is using C++ so this would probably break rapidsvn if you upgrade APR/httpd2 with this change in the future. Which I think would be kinda bad. > We could fudge apr_off_t to still be a long on platforms where it was > already or even on all platforms with a 32-bit long if anyone really > cares. It might be wise anyway... could compilers specify different > structure padding/alignment/calling conventions for int and long even > though they are the same size? Hmmm... I doubt the compiler treats int or long any different on the platforms where they're the same size. I see people misuse int in place of long and it works fine until they port it to another platform, where it isn't the same size. This is a big reason why moving code over to 64-bit archs has been such a hassle. So I guess I'll look into redoing it to use int, long or long long instead. -- Ben Reser http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken