On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson <h...@bitrange.com> 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 <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. >> * 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
