Version: 2.3.4
Platform: Solaris (possibly other non-Linux).

In some cases reentrant API functions (ctime_r etc) are
used, but many cases not.  It's unlikely that this
would cause problems on single-processor machines. Run
the attached script giving Python source tree location
as argument.  A file report.html will be generated
detailing where there could be problems.

NB:  The script isn't foolproof and will come up with
matches to text inside comments as well.

Logged In: YES 
user_id=21627

I fail to see the bug. I believe Python uses the reentrant
functions at precisely the places where it is necessary, and
is right in using the non-reentrant functions in all other
places. To my knowledge, the way that Python uses the
non-reentrant functions cannot possibly cause problems even
on multiprocessor machines.

So I'm closing this report as invalid. If you can find an
actual problem using your script, please submit a new bug
report.

Logged In: YES 
user_id=21627

In private email, Simon pointed out that there is a problem
if Python is embedded and the embedded application
simultaneously also invokes non-reentrant functions. I'm
still uncertain whether that problem would be a bug in
Python, and if it is, whether it is worthwhile getting fixed.

OTOH, contributions would be certainly accepted.

Logged In: YES 
user_id=775521

Don't apply the patch - it's not tested, but just serves as
an example, and it's certainly not complete.

For some _r functions it's quite obvious how they should be
used.  For ones with variable-length buffers accompanying
the struct to be filled in it's not clear how they should be
sized. It's also not clear whether the ERANGE return should
be used to 'automatically' realloc a larger buffer, or
whether the ERANGE error should simply be passed back to
Python as a general failure.  For some buffers (asctime_r)
the maximum size can be guessed based on common sense, for
others, defines exist in system headers which may not be
portable, requiring possible further configure checks.

I think the way I would fix this is to introduce a wrapper
for each reentrant function that returns a malloc'ed buffer
that must be freed by the caller when done with the
structure.  The wrapper would continually allocate larger
buffers until the size was correct.

Alteratively, one might argue I'm being overly paranoid, and
that for each function we should be able to guess a sensible
buffer length, then just fail if the api call returns too
much data.  

Logged In: YES 
user_id=21627

The patch looks good. It doesn't need to be complete, but it
should be correct for the APIs which it does change. A few
comments:
- there is probably little point in changing getaddrinfo.c.
This is an emulation that is only used on systems which
don't have a "proper" getaddrinfo, and most likely, all
systems offering gethostbyname_r also offer getaddrinfo.
- the usage of readdir_r is incorrect - you need to provide
for sufficient space.
- I don't think it is good to allocate 8k on the stack.
Instead, you should indeed start with a small buffer, then
grow it as needed, using malloc.

Logged In: YES 
user_id=775521

Point taken about readdir_r and getaddrinfo.  I'll submit
something more robust (and tested) probably next week.

Logged In: YES 
user_id=775521

I'm still looking at this, but running into difficulties.  

- Having looked again at readdir_r manual page I can't work
out the buffer sizing.  If anyone can point me at some
example code I'd appreciate it.
- I can't compile 2.4a3 on Solaris - got an error during
configure about term.h present but can't be compiled, and
therefore can't check my latest patch works.  System:
Solaris 8 2/02, gcc 3.3.3.  I'm not in a position to change
any of these versions, unfortunately.

Logged In: YES 
user_id=21627

One approach of using readdir_r is presented at

http://www.belgeler.org/glibc/glibc-Reading-Closing-Directory.html

As for not being able to compile 2.4a3, please add a new bug
report, and show the relevant fragment of config.log in that
report.

Check this for 2.6 or close it.

Is this still a concern?

No reply to msg82073.