This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson <> wrote:
> On Mon, 19 May 2014, 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  <>
>>     PR libfortran/60324
>>     * Regenerated.
>>     * configure: Regenerated.
>>     * (AC_CHECK_FUNCS_ONCE): Check for strnlen and
>>     strndup.
>>     * libgfortran.h (fc_strdup): New prototype.
>>     * runtime/string.c (strnlen): New fallback function.
>>     (strndup): New fallback function.
>>     (fc_strdup): New function.
>>     * io/close.c (st_close): Use fc_strdup.
>>     * io/open.c (new_unit): Likewise.
>>     (already_open): Likewise.
>>     * io/unit.c (filename_from_unit): Likewise.
>>     * io/unix.c (unpack_filename): Remove function.
>>     (regular_file): Rename to regular_file2, add path argument.
>>     (regular_file): New function calling regular_file2.
>>     (compare_file_filename): Use fc_strdup.
>>     (find_file): Likewise.
>>     (delete_file): Likewise.
>>     (file_exists): Likewise.
>>     (file_size): Likewise.
>>     (inquire_sequential): Likewise.
>>     (inquire_direct): Likewise.
>>     (inquire_formatted): Likewise.
>>     (inquire_access): Likewise.
>>     * io/unix.h (unpack_filename): Remove prototype.
>>     * runtime/main.c (please_free_exe_path_when_done): Change type to
>>     bool.
>>     (store_exe_path): Use malloced buffer, grow as needed.
> This patch broke build for newlib targets; you need AC_DEFINE
> clauses for those in the "if-then"-leg where you patched the
> "else"-leg.

Do I? The patch does include fallback implementations for strnlen and
strndup in case the target doesn't supply them. I don't know whether
newlib does, or if current versions do have it but old still in use
versions don't etc. I suggest that whoever was insisting on this
stupid hard-coded func list for newlib takes care of figuring that out
and, if it turns out that all relevant newlib versions do supply one
or both of those functions, posts a patch.

Or hmm, is there some symbol name conflict, in case we try to use a
fallback implementation but the target already defines it?

> There's also a need for #include <stdlib.h> for the
> malloc use in runtime/string.c.

This, OTOH, is clearly a bug. Committed the obvious bugfix as r210827,
thanks for reporting. (Annoying that glibc apparently defines malloc
via some other includes as well so I didn't notice it.)

Janne Blomqvist

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]