From dev-return-10567-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Nov 05 00:05:10 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 37132 invoked from network); 5 Nov 2003 00:05:10 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 5 Nov 2003 00:05:10 -0000 Received: (qmail 68426 invoked by uid 500); 5 Nov 2003 00:04:55 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 68253 invoked by uid 500); 5 Nov 2003 00:04:54 -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 68239 invoked from network); 5 Nov 2003 00:04:53 -0000 Date: Wed, 5 Nov 2003 00:04:27 +0000 From: Joe Orton To: dev@apr.apache.org Subject: Re: cvs commit: apr/test testrand2.c Makefile.in test_apr.h testall.c Message-ID: <20031105000427.GA9631@manyfish.co.uk> Mail-Followup-To: dev@apr.apache.org References: <20031103132501.72702.qmail@minotaur.apache.org> <20031104093402.GB15655@manyfish.co.uk> <3FA83063.2030603@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3FA83063.2030603@algroup.co.uk> User-Agent: Mutt/1.4.1i 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 Tue, Nov 04, 2003 at 11:04:03PM +0000, Ben Laurie wrote: > Joe Orton wrote: > > > On Mon, Nov 03, 2003 at 01:25:01PM -0000, Ben Laurie wrote: > >> Start of new PRNG. > > > > > > It would have been nice to fix some of the portability problems *before* > > checking this in and breaking the HEAD build on most platforms. :( I'll > > take the directory out of apr_modules for the moment. > > How do I fix portability problems given that I only own one platform? In > any case, isn't it better from a change trail POV to do it _after_ checkin? > > Finally, this amounts to an "it doesn't work" bug report - more details, > please? The integer types in the sha code and the C++ comments are the major issues of those I pointed out already - it also needs AC_C_BIGENDIAN adding to configure and use of WORDS_BIGENDIAN in the code, BYTE_ORDER is not portable either. Fixing the code style before initial check-in would avoid trashing the cvs history with whitespace changes later... never mind.