Mail Archives: djgpp-workers/2005/01/01/11:32:43
On Sat, 01 Jan 2005 12:57:25 +0200, Eli Zaretskii <eliz AT gnu DOT org>
wrote:
>> Date: Fri, 31 Dec 2004 23:01:02 -0700
>> From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
>>
>> >You just define your (POSIX) functions that does the real work, adding
>> >them as stubs to <libc/stubs.h> and letting the C (89 or 99) call them
>> >as necessary.
>>
>> I am not sure what you mean by stubs here?
>
>See src/libc/stubs/mkstubs.c. This program is invoked during the
>library build; it scans the libc/stubs.h header and for each stub
>there produces a stubNN.S file that defines a function which simply
>jmp's to its alias. Thus, e.g., localtime_r will simply jmp to
>localtime. The resulting stubNN.S files are then assembled and linked
>into libc.a.
>
>> If the POSIX functions are not declared by including the appropriate
>> header, or by calling them with a local declaration in scope, or if
>> compiler options specify -ansi, we should not pollute the ISO Standard
>> C namespace.
>
>The stub method solves this problem, as you only get localtime_r
>linked in if you reference it in your program.
>
>The question is, as I wrote elsewhere in this thread, do we want the
>*_r functions as simple aliases for the non-*_r functions, or do we
>really want reentrancy.
The *_r _POSIX_THREAD_SAFE_FUNCTIONS have different interfaces that
support reentrancy/threads by allowing the caller to pass a
buffer/struct pointer instead of using/returning an internal static
buffer/struct.
The ISO interfaces can just allocate their static buffer/struct and
call the internal _*_r function, whereas the POSIX *_r interface can
be stubbed jumps to the internal _*_r function.
--
Thanks. Take care, Brian Inglis
- Raw text -