Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 98448 invoked by uid 500); 15 Apr 2003 18:41:55 -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 98435 invoked from network); 15 Apr 2003 18:41:55 -0000 Message-ID: <3E9C52AE.1060502@attglobal.net> Date: Tue, 15 Apr 2003 14:42:54 -0400 From: Jeff Trawick Reply-To: trawick@attglobal.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org Subject: apr_atomic_cas() interface Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N why is it apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *, long, long) (generic version) apr_uint32_t apr_atomic_cas(volatile apr_atomic_t *, apr_uint32_t, apr_uint32_t cmp) (MVS version) instead of apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *, apr_uint32_t, apr_uint32_t) everywhere? The MVS version just has a typographical difference to what is needed (apr_atomic_t vs. apr_uint32_t, which are the same). The generic version is broken where long is 64-bit. Is there some reason why "long" was chosen for the 2nd and 3rd parameters.