Re: [PATCH, libgfortran] PR60324 Handle arbitrarily long path names

2014-05-21 Thread Steve Kargl
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  j...@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


Re: [PATCH, libgfortran] PR60324 Handle arbitrarily long path names

2014-05-21 Thread Janne Blomqvist
On Wed, May 21, 2014 at 4:35 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
 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  j...@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.

Thanks for the review. The fc_ prefix is shorthand for fortran-to-c,
as fc_strdup converts a Fortran string to a C string. Similar to the
existing cf_strcpy and fstrlen.


-- 
Janne Blomqvist