Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of ehuels@gmail.com designates
 64.233.184.201 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OPq+ofY8kopGFPOnFoQ0oaD+bjSjLcrWcFei0+1CDEosbr7ZFjw3J60DcYLMQJB4cjPoAy/uTsKxYESXOedPBSrwCpFDs4Ez1DYI1Ds5/yTRNw+CwDYEsmheZUdDNskpVSTvM8tFXh/3zdeRxqqZjnoIhXQJGaexhukiHN0GiuM=
Message-ID: <aea328ab05042607513566a5fa@mail.gmail.com>
Date: Tue, 26 Apr 2005 16:51:57 +0200
From: Erik Huelsmann <ehuels@gmail.com>
Reply-To: Erik Huelsmann <ehuels@gmail.com>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PATCH] Don't define POSIX types {p,g,u}id_t
Cc: dev@apr.apache.org
In-Reply-To: <6.2.1.2.2.20050426084546.05fc0990@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <aea328ab050425230978094dc8@mail.gmail.com>
	 <20050426101414.GD16976@redhat.com>
	 <aea328ab050426062460d70045@mail.gmail.com>
	 <6.2.1.2.2.20050426084546.05fc0990@pop3.rowe-clan.net>

On 4/26/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> At 08:24 AM 4/26/2005, Erik Huelsmann wrote:
> >On 4/26/05, Joe Orton <jorton@redhat.com> wrote:
> >>
> >> Will this not break programs on Windows which hitherto presumed that A=
PR
> >> defines these types?  i.e. it breaks the source-compatibility API
> >> guarantee for APR 1.x?
> >
> >Yes, it does, if you consider that an APR api promise. I don't: I
> >consider it an unfortunate side effect of header file structuring (a
> >bug to be fixed): the APR type to use (in 1.1.x) always has been
> >apr_os_proc_t which serves the purpose of pid_t in a platform
> >independent way.
>=20
> As 0.9 API is considered released/stable, backporting isn't an
> option.  We could replace with a #ifndef / #define construct,
> but in 0.9, the symbol has to remain.

Well, although I understand your reasons, my reasoning is that it was
never and still isn't part of the API: it's not part of the apr_* and
APR_* name spaces.
=20
> Actually deprecating this before 2.0 is problematic as well,
> although using apr_os_pid_t in 0.9 here forward is goodness.

I actually disagree: the long term solution would be to use
apr_os_proc_t where I currently introduced apr_os_pid_t: that's the
type for the purpose. I wanted to maintain binary compatibility, so I
solved it this way. Also, using apr_os_proc_t causes a circular
reference in the header files: it's required by apr_thread_proc.h and
defined in apr_portable.h (which includes apr_thread_proc)....


Just my opinion, but if you don't kill {p,u,g}id_t from the interface,
then I don't see any reason to use the patch either. But if you don't
kill them, you're not even helping my problem in the long run. (Given
the compat rules, I didn't even hope for short-term help...)


bye,

Erik.