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
