Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Fri, 20 Apr 2001 22:49:35 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Cc: newlib AT sources DOT redhat DOT com
Subject: Re: vfscanf in newlib
Message-ID: <20010420224935.A4247@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com, newlib AT sources DOT redhat DOT com
References: <3ADD0441 DOT 91F76FB6 AT ece DOT gatech DOT edu> <3ADE1FC1 DOT F0A10A89 AT cygnus DOT com> <3ADE640A DOT 34E88DCE AT ece DOT gatech DOT edu> <3AE040FC DOT 16BD67BC AT ece DOT gatech DOT edu> <3AE070F3 DOT 1C45633A AT cygnus DOT com> <20010420145228 DOT B25768 AT redhat DOT com> <3AE0894D DOT 5288FDF3 AT cygnus DOT com> <20010420152744 DOT A26175 AT redhat DOT com> <3AE0E6C9 DOT CFA716BF AT ece DOT gatech DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <3AE0E6C9.CFA716BF@ece.gatech.edu>; from cwilson@ece.gatech.edu on Fri, Apr 20, 2001 at 09:47:53PM -0400

On Fri, Apr 20, 2001 at 09:47:53PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>> >J Johnston wrote:
>> >As discussed, I have attached the new patch.  I moved stuff around in stdio.h
>> >because there were multiple sections using the same #ifdef.  There were also
>> >some routines that were not properly under the non-strict ANSI flag.
>> 
>> I'm not sure if this is directed to me, but I was just asking Chuck for the
>> appropriate cygwin.din changes.
>> 
>> I decided that it was silly for me to ask him to do this since it is easy to
>> do myself, though, so I've made the appropriate modifications.  So, if/when you
>> check this in we'll be ready.
>
>Great -- thanks for taking care of that.  One comment, though:
>
>if the undecorated symbol is 
>  _vscanf_r
>then the decorated symbol should be 
> __vscanf_r
>
>So, shouldn't cygwin.din have
>_vscanf_r
>__vscanf_r = _vscanf_r
>
>Your patch has
>_vscanf_f
>vscanf_r = _vscanf_r

The way that it is built currently exposes a _vscanf_r and a vscanf_r to the
user.  This is similar to the way other functions are defined in cygwin.din.

With the current definitions, this works:

int
main (int argc, char **argv)
{
   char foo[100];
  int bar;
  _vscanf_r (foo, "", &bar);
  vscanf_r (foo, "", &bar);
}

__vscanf_r won't work, and I don't think that it should.

I am not sure why the _r functions were created with an underscore.  I
couldn't find anything in the Single Unix Specification which talked
about a _r function for scanf.  It did seem inconsistent to export
symbols with two leading underscores, though.

I just checked and see that there are a few functions defined that way
now but I'm not sure what the rationale for doing things this way is.

Jeff, could you explain why the _r functions have a leading underscore?
Is this because they are newlib-only functions, i.e., they don't seem to
adhere to a standard?

cgf