X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.1 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_KR,TW_VP,TW_YG
X-Spam-Check-By: sourceware.org
Message-ID: <4C75E122.4070104@cwilson.fastmail.fm>
Date: Wed, 25 Aug 2010 23:36:02 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
References: <201008191720 DOT o7JHKGoE008398 AT mx1 DOT redhat DOT com> <4C6F1F4A DOT 2030901 AT redhat DOT com> <4C6F26DA DOT 2090009 AT cwilson DOT fastmail DOT fm> <20100821085401 DOT GP11340 AT calimero DOT vinschen DOT de>
In-Reply-To: <20100821085401.GP11340@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 8/21/2010 4:54 AM, Corinna Vinschen wrote:
> On Aug 20 21:07, Charles Wilson wrote:
>> If you concur, I'll post a patch to that effect to cygwin-patches (we
>> use our own header, not newlib's, for netinet/in.h).
> 
> This is not the right solution.

OK.

> First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you
> can see in the comment in /usr/include/features.h, the groundwork is
> entirely missing.  The _POSIX_SOURCE is used in newlib in the first
> place and we can and do use it as well.  _XOPEN_SOURCE is only barely
> available for a few months now, but it's not actually used anywhere.

I see.

> On Linux, bindresvport and bindresvport6 are available by default,
> *unless* you define something like _POSIX_SOURCE. 

Right...as you pointed out below, you get the same warning on linux.

> Since newlib/Cygwin
> is missing the groundwork for a full-fledged features.h, your above
> suggestion would result in declaring bindresvport/bindresvport_sa *only
> if*  the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the
> command line.  That's not feasible.

Yes, you are correct. :-(

> The question is, why does libtirpc declare the functions at all?  Does
> it come with its own implementation? 

Yes, it does.  And, that implementation is used by the upstream source
for linux, in preference to the glibc-provided version.  I followed that
pattern in libtirpc, as well: the libtirpc version is used in preference
to cygwin's.

Not because I think there is a problem with cygwin's, but simply because
I followed the linux pattern.

Given that, I think something similar to the krb5 solution could be used
here, as well.

Unfortunately, the current cygtirpc-1.dll exports its version of
bindresvport and bindresvport_sa. That is a *problem* because anything
built against it will expect to use ITS version from now on.

Unless I rebuild with renamed versions, and bump the API number.

Or, don't bump the API number and break stuff. Since it is a new
package, and so far only Erick's private libvirt seems to use it, I'm
actually leaning that way.

Eric, any thoughts?

> Whether or not, I think the
> problem are the libtirpc headers in the first place.

OK.

> But note that this only occurs with -Wredundant-decls, which is not one
> of the default warnings.

right, but this problem did lead to the discovery of a real issue in
cygtirpc-1.dll...

I wonder if there are more issues lurking here:

The following are exported by both cygtirpc-1.dll and cygwin1.dll:
	bindresvport
	bindresvport_sa
	getpeereid (*)

(*) implemented using
        error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, &uc, &uclen);
    and then picking uc.uid and uc.gid (after error checking, etc).


Note that there are a number of functions declared by cygwin's <netdb.h>
header, but are provided by cygtirpc:

void            endrpcent  (void);
struct rpcent   *getrpcent (void);
struct rpcent   *getrpcbyname (const char *);
struct rpcent   *getrpcbynumber (int);
void            setrpcent (int);

Interestingly, many of these apparently HAD been declared in
tirpc/rpc/rpcent.h, but were commented out (using C++ comment markers, I
might add).  But, at least that means there is no conflict with these
symbols.

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple