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 16:31:24 +1200
- CC: java-patches at gcc dot gnu dot org
- References: <Pine.LNX.4.10.10105292358300.26081-100000@mars.deadcafe.org>
Jeff Sturm wrote:
> On sparc-solaris, I find File.list() somtimes dumps core, for instance if
> libgcj is compiled with -O0. In natFile.cc we have
>
> struct dirent *d, d2;
> while ((d = get_entry (dir, &d2)) != NULL)
>
> and
>
> static struct dirent *
> get_entry (DIR *dir, struct dirent *e)
> {
> struct dirent *r;
> if (readdir_r (dir, e, &r) || r == NULL)
>
> but the info page for readdir_r says `e' must be at least (sizeof (struct
> dirent) + NAME_MAX + 1) bytes. Oops.
Should we really be using these *_r functions anyway? In glibc I get the
impression that they are really only there for backwards compatibility, and I have
a feeling that they are generally less tested and more buggy than the normal ones.
Are there really any platforms out there that still don't have threadsafe
implementations of the "normal" IO routines?
regards
[ bryce ]