This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PATCH: fix buffer overrun in natFile.cc
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: PATCH: fix buffer overrun in natFile.cc
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Date: Wed, 30 May 2001 17:35:09 +1200
- CC: java-patches at gcc dot gnu dot org
- References: <Pine.LNX.4.10.10105300049060.27669-100000@mars.deadcafe.org>
Jeff Sturm wrote:
> > In glibc I get the impression that they are really only there for
> > backwards compatibility,
>
> I haven't looked at glibc's readdir. Certainly it ought to be simple
> to do something with thread-local storage.
>
> > Are there really any platforms out there that still don't have threadsafe
> > implementations of the "normal" IO routines?
>
> The Solaris 2.7 man page only says "the readdir() function is unsafe in
> multithreaded applications". There's not much more detail than that. I
> suppose we're forced to trust them.
OK, on closer inspection, glibc also says readdir isn't thread safe (and
encouranges readdir_r as an alternative). I was actually thinking about
gethostbyname and friends in java.net, which definatly are threadsafe in
glibc, and whose _r variants are completely undocumented.
Anyhow, can we get away with a stack allocation (ie char[sizeof(...)
+ NAME_MAX +1];) instead of the malloc? Shouldn't NAME_MAX always be
available, at least wherever readdir_r is?
For simplicity it might be worth dropping the _JV_POSIX_THREADS test and just
using HAVE_READDIR_R.
regards
[ bryce ]