Mail Archives: cygwin-developers/2001/04/20/22:49:29
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
- Raw text -