Mail Archives: djgpp-workers/2005/01/01/01:03:25
On Sat, 01 Jan 2005 04:13:50 +0100 (CET), ams AT ludd DOT ltu DOT se wrote:
>According to Brian Inglis:
>> On Sat, 01 Jan 2005 02:19:31 +0100 (CET), ams AT ludd DOT ltu DOT se wrote:
>>
>> >According to Brian Inglis:
>> >> On Fri, 31 Dec 2004 13:42:52 +0100 (CET), ams AT ludd DOT ltu DOT se wrote:
>> >...
>> >> >Missing POSIX functions:
>> >> >asctime_r
>> >> >ctime_r
>> >> >gmtime_r
>> >> >localtime_r
>> >> >strptime
>> >>
>> >> I can supply those as part of my changes to time functions.
>> >
>> >Let's hear it! (Post the patches, i.e.)
>>
>> How do we want to handle these?
>> The ISO functions become wrappers which define static storage and call
>> the POSIX *_r functions.
>
>ISO == standard C, I think you mean, right?
Yup, as opposed to POSIX standard C functions.
>> Do we want to define the POSIX functions as _*_r and then use the
>> _/environ approach to define them when referenced, have the POSIX
>> headers #define *_r as _*_r, or have POSIX functions *_r call _*_r?
>
>Even though I'm embriated, I think the plan would be to handle these
ine...?
>as stubs and thus not needing the environ approach.
We need two interfaces and two/three functions: an ISO interface, a
POSIX interface, and that could also be the worker function: e.g.
ctime(), ctime_r(), and (say) _ctime_r().
>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?
>I might be misssing something here...
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.
--
Thanks. Take care, Brian Inglis
- Raw text -