Re: reentrant functions

[Bas van Gompel <cygwin dot buzz at bavag dot tmfweb dot nl>]

Op Fri, 9 Apr 2004 00:01:56 -0400
schreef Christopher Faylor <cgf-no-personal-reply-please uit cygwin.com>
in <20040409040156.GA4342@coe>:
:  On Fri, Apr 09, 2004 at 04:33:26AM +0200, Bas van Gompel wrote:
[don't export _r functions which are only in newlib and in no UNIX]

: > Yeah, sure. But this means I won't be able to help any further
: > with this, as I don't know which UNIXes export which functions,.
:
:   Fair enough.
:
:  My previous message was somewhat garbled.  Let me try again.

Ok.

:  Corinna did not provide enough guidelines in stating what was required.
:  I was attempting to clarify that it wasn't enough to just get a list of
:  all *_r from newlib which are not exported by cygwin.  Although I gave a
:  vague "UNIX" guideline I did not offer any clear way for you to
:  determine which functions should be exported.
:
:  I gave you an example of one such routine but I was too demure in my
:  presentation.  mallopt_r is definitely something that we do not want to
:  include, as is realloc_r, and malloc_r, free_r, gettimeofday_r, and
:  tmpfile_r.  The reason why these are not desired is that newlib defines
:  a number of _r type functions that do not exist on linux or in the
:  Single UNIX Specification.

That's clear now.

:  For a reference of what is acceptable, you can use The Single Unix
:  Specification v3:
:
:  http://www.opengroup.org/onlinepubs/007904975/toc.htm

Interesting document.

:  This reference would be adequate in determining what to include but,
:  if in doubt about something that seems like a useful function, then
:  double checking with linux should be adequate.
:
:  The SUSv3 reference does not define the mallopt function but functions
:  not ending in _r are not the subject of this exercise.  We are trying to
:  export the reentrant routines which have a UNIX analog.  We're not
:  trying to bloat cygwin with reentrant routines that no one else uses.

Would it be an idea to create a separate library with those other
functions? (Some look like they might be usable.)

:  There is also another reason not to use mallopt_r -- cygwin doesn't use
:  the malloc version in newlib so exporting any of the _r malloc functions
:  from newlib would cause runtime errors for anyone who used them.

Now there's a reason! :)

[mallopt on UNIXen}

:  Again, the criteria is not to export every _r function for which there
:  is an exported non-_r function.  We only want to export the ones that
:  make sense for a UNIX environment.

Ok then, another try...

Candidates getgrgid_r, getgrnam_r and getlogin_r are not
implemented.

ttyname_r appears to be implemented only for linux
(in newlib/libc/sys/linux/ttyname_r.c).

ctime_r, asctime_r, getpwnam_r, getpwuid_r, gmtime_r, localtime_r,
strerror_r and strtok_r are already exported.

That leaves:
====
rand_r
readdir_r
====

Is this any better?

(The OP is not gonna like this, as he wanted _gets_r.)

L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/