From dev-return-24449-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Oct 18 21:33:45 2011 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 52F027A2B for ; Tue, 18 Oct 2011 21:33:45 +0000 (UTC) Received: (qmail 10925 invoked by uid 500); 18 Oct 2011 21:33:45 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 10840 invoked by uid 500); 18 Oct 2011 21:33:44 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 10832 invoked by uid 99); 18 Oct 2011 21:33:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Oct 2011 21:33:44 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.214.50 as permitted sender) Received: from [209.85.214.50] (HELO mail-bw0-f50.google.com) (209.85.214.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Oct 2011 21:33:37 +0000 Received: by bkaq10 with SMTP id q10so1569951bka.37 for ; Tue, 18 Oct 2011 14:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N15nw/sNNeztgq9GjS1pCUniW0SK7q1qh9WToosRaQ8=; b=B5IlMzWslyKV4zF6KODGRRyahWWqHPDZ5W6i+twrvLdZt8xUmYBQ/R0Fy/bK6GAQPS 8mmkKotCZnRDXGCkOBWsrNAMgn3borlyWn8Nq2n9ufehnrMv0A9l3KqspBMInN8yD2y2 RMGb00Xm4h40PQh4PcPUU5Ef1BXbJk2wpAqzg= MIME-Version: 1.0 Received: by 10.204.50.88 with SMTP id y24mr3077719bkf.53.1318973597537; Tue, 18 Oct 2011 14:33:17 -0700 (PDT) Received: by 10.204.100.139 with HTTP; Tue, 18 Oct 2011 14:33:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Oct 2011 17:33:17 -0400 Message-ID: Subject: Re: redefinition uid_t From: Jeff Trawick To: dev@apr.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Oct 18, 2011 at 9:26 AM, Oscar Pernas wrote: > Hi all, > I'm using apr in a process that uses CORBA TAO, for communications. My > problem is that TAO and APR has the same redefinition of a variable. > In apr.h i can see: > typedef int uid_t ; > typedef int pid_t; > typedef int gid_t; > However in TAO I could see: > typedef long uid_t > typedef long pid_t > > Im in Win32 and Win64 platform. I've commented it in apr source and library > compiles well, Could I have any problem? What would be the best solution? I think that's the best solution for now. APR doesn't actually need to define uid_t for its own purposes. That general issue -- defining Unix types -- should be be fixed in the next major (i.e., not binary compatible) release. In cases other than uid_t there may be other fallout to handle. For example, apr_proc_t uses (requires) pid_t. According to our API compatibility rules, something equivalent to #ifndef APR_PLEASE_DONT_DEFINE_UNIX_TYPES typedef whatever uid_t #endif could be provided with apr 1.5.x. That would be worthwhile if the fix could be near-complete. (I dunno the complete fallout.)