vfscanf in newlib

Christopher Faylor cgf@redhat.com
Fri Apr 20 19:49:00 GMT 2001

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
>Your patch has
>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:

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?


More information about the Cygwin-developers mailing list