This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, libgfortran] PR60324 Handle arbitrarily long path names
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 May 2014 06:35:28 -0700
- Subject: Re: [PATCH, libgfortran] PR60324 Handle arbitrarily long path names
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9GrALPvDLes3vkeMsULZYOV4fFtUTuLvEwP6vw+5G8=Kw at mail dot gmail dot com>
On Mon, May 19, 2014 at 11:40:06PM +0300, Janne Blomqvist wrote:
> Hello,
>
> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
> some other systems many syscalls apparently work for paths longer than
> PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
> characters, but rather use heap allocated buffers limited only by the
> available memory. The attached patch implements this, with the
> exception of the backtrace functionality where we cannot use malloc
> since backtrace might be called from a signal handler.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2014-05-19 Janne Blomqvist <jb@gcc.gnu.org>
>
> PR libfortran/60324
> * config.h.in: Regenerated.
> * configure: Regenerated.
> * configure.ac (AC_CHECK_FUNCS_ONCE): Check for strnlen and
> strndup.
> * libgfortran.h (fc_strdup): New prototype.
Janne,
I read through the diff, and did not see anything that threw up
a caution sign. I only have a cosmetic question. Why a fc_
prefix instead of the usual gfc_ prefix? Otherwise, I think
this is OK for trunk.
--
Steve