[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #10 from Janne Blomqvist --- Author: jb Date: Sun Nov 16 01:56:54 2014 New Revision: 217623 URL: https://gcc.gnu.org/viewcvs?rev=217623&root=gcc&view=rev Log: PR 60324 VLA related fixes to random number generator. 2014-11-16 Janne Blomqvist PR libfortran/60324 * intrinsics/random.c (kiss_size): Rename to KISS_SIZE, make it a macro instead of a variable. (random_seed_i4): Make seed correct size, remove assert, KISS_SIZE related changes. (random_seed_i8): KISS_SIZE related changes. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/random.c
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Janne Blomqvist changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #8 from Janne Blomqvist --- Author: jb Date: Thu Nov 13 12:05:01 2014 New Revision: 217480 URL: https://gcc.gnu.org/viewcvs?rev=217480&root=gcc&view=rev Log: PR 60324 Unbounded stack allocations in libgfortran. 2014-11-13 Janne Blomqvist PR libfortran/60324 * configure: Regenerated. * configure.ac (AM_CFLAGS): Add Werror=vla. * libgfortran.h (gfc_alloca): Remove macro. (fc_strdup_notrim): New prototype. * intrinsics/access.c (access_func): Use fc_strdup rather than stack allocation. * intrinsics/chdir.c (chdir_i4_sub): Likewise. (chdir_i8_sub): Likewise. * intrinsics/chmod.c (chmod_internal): New function, move logic here. (chmod_func): Call chmod_internal. * intrinsics/env.c (getenv): Use fc_strdup rather than stack allocation. (get_environment_variable_i4): Likewise. * intrinsics/execute_command_line.c (execute_command_line): Likewise. * intrinsics/hostnm.c (hostnm_0): New function, use static buffer rather than VLA. (hostnm_i4_sub): Call hostnm_0. (hostnm_i8_sub): Likewise. (hostnm): Likewise. * intrinsics/link.c (link_internal): New function, use fc_strdup rather than stack allocation. (link_i4_sub): Call link_internal. (link_i8_sub): Likewise. (link_i4): Likewise. (link_i8): Likewise. * intrinsics/perror.c (perror_sub): Use fc_strdup rather than stack allocation. * intrinsics/random.c (random_seed_i4): Use static buffer rather than VLA, use _Static_assert to make sure it's big enough. * intrinsics/rename.c (rename_internal): New function, use fc_strdup rather than stack allocation. (rename_i4_sub): Call rename_internal. (rename_i8_sub): Likewise. (rename_i4): Likewise. (rename_i8): Likewise. * intrinsics/stat.c (stat_i4_sub_0): Use fc_strdup rather than stack allocation. (stat_i8_sub_0): Likewise. * intrinsics/symlink.c (symlnk_internal): New function, use fc_strdup rather than stack allocation. (symlnk_i4_sub): Call symlnk_internal. (symlnk_i8_sub): Likewise. (symlnk_i4): Likewise. (symlnk_i8): Likewise. * intrinsics/system.c (system_sub): Use fc_strdup rather than stack allocation. * intrinsics/unlink.c (unlink_i4_sub): Likewise. * io/file_pos.c (READ_CHUNK): Make it a macro rather than variable. * io/list_read.c (nml_get_obj_data): Use fixed stack buffer, fall back to xmalloc/free for large sizes. * io/read.c (read_f): Likewise. * io/transfer.c (MAX_READ): Make it a macro rather than variable. (WRITE_CHUNK): Likewise. * io/write_float.def (write_float): Use fixed stack buffer, fall back to xmalloc/free for large sizes. * runtime/string.c (fc_strdup_notrim): New function. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/access.c trunk/libgfortran/intrinsics/chdir.c trunk/libgfortran/intrinsics/chmod.c trunk/libgfortran/intrinsics/env.c trunk/libgfortran/intrinsics/execute_command_line.c trunk/libgfortran/intrinsics/hostnm.c trunk/libgfortran/intrinsics/link.c trunk/libgfortran/intrinsics/perror.c trunk/libgfortran/intrinsics/random.c trunk/libgfortran/intrinsics/rename.c trunk/libgfortran/intrinsics/stat.c trunk/libgfortran/intrinsics/symlnk.c trunk/libgfortran/intrinsics/system.c trunk/libgfortran/intrinsics/unlink.c trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write_float.def trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/string.c
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #7 from Janne Blomqvist --- (In reply to Rich Townsend from comment #6) > This change introduces a dependency on strndup -- which, alas, is absent > from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X > include it. This isn't a problem per se, as it appears that an internal > strndup will be built if a system one can't be found. Indeed. This is similar to how libgfortran handles a lot of functionality beyond basic C89 + POSIX. > Howver, today, I've run into the problem that when I build gcc/gfortran > (trunk) on 10.9, I can't then use the compiler on 10.6 due to the reference > in libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any > suggestions for workarounds? Can I hack libgfortran/configure.ac to force > the internal strndup to be used? I think hacking configure.ac is how people doing cross-compilers etc. typically do it, so it should work, yes. configure.ac does already have such a hard-coded list for newlib targets, take a look at that, it ought to be relatively straightforward to create a similar list for OSX. Another alternative would be for you to compile gfortran on your 10.6 system, the result should be usable on a 10.9 system as well. The strnlen/strndup implementations provided by the target system might be faster compared to the simple fallback implementations in libgfortran, but for the usage in libgfortran it's unlikely to be an issue.
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Rich Townsend changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #6 from Rich Townsend --- This change introduces a dependency on strndup -- which, alas, is absent from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X include it. This isn't a problem per se, as it appears that an internal strndup will be built if a system one can't be found. Howver, today, I've run into the problem that when I build gcc/gfortran (trunk) on 10.9, I can't then use the compiler on 10.6 due to the reference in libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any suggestions for workarounds? Can I hack libgfortran/configure.ac to force the internal strndup to be used? cheers, Rich
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Janne Blomqvist changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Janne Blomqvist --- There are still a number of cases (IO intrinsics, mostly) where we create a null-terminated copy of a potentially unbounded input string on the stack, leading to a potential stack overflow crash. But the stack limit is usually several MB versus a few KB for PATH_MAX, so unlikely to be an issue in practice.
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Francois-Xavier Coudert --- I take it this one can be closed :)
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Thu May 22 21:17:29 2014 New Revision: 210827 URL: http://gcc.gnu.org/viewcvs?rev=210827&root=gcc&view=rev Log: PR 60324 Handle long path names, don't use PATH_MAX. 2014-05-23 Janne Blomqvist PR libfortran/60324 * runtime/string.c: Include stdlib.h. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/string.c
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Thu May 22 03:51:25 2014 New Revision: 210738 URL: http://gcc.gnu.org/viewcvs?rev=210738&root=gcc&view=rev Log: PR 60324 Handle long path names, don't use PATH_MAX. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/close.c trunk/libgfortran/io/open.c trunk/libgfortran/io/unit.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/main.c trunk/libgfortran/runtime/string.c
[Bug libfortran/60324] Handle arbitrarily long path names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-30 Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Janne Blomqvist --- Assigning to myself, working on a patch.
