* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
@ 2014-04-30 22:30 ` jb at gcc dot gnu.org
2014-05-22 3:52 ` jb at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-04-30 22:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist <jb at gcc dot gnu.org> 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 <jb at gcc dot gnu.org> ---
Assigning to myself, working on a patch.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
2014-04-30 22:30 ` [Bug libfortran/60324] Handle arbitrarily long path names jb at gcc dot gnu.org
@ 2014-05-22 3:52 ` jb at gcc dot gnu.org
2014-05-22 21:18 ` jb at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-05-22 3:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
2014-04-30 22:30 ` [Bug libfortran/60324] Handle arbitrarily long path names jb at gcc dot gnu.org
2014-05-22 3:52 ` jb at gcc dot gnu.org
@ 2014-05-22 21:18 ` jb at gcc dot gnu.org
2014-06-08 16:44 ` fxcoudert at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-05-22 21:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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 <jb@gcc.gnu.org>
PR libfortran/60324
* runtime/string.c: Include stdlib.h.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/string.c
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-05-22 21:18 ` jb at gcc dot gnu.org
@ 2014-06-08 16:44 ` fxcoudert at gcc dot gnu.org
2014-06-10 10:21 ` jb at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2014-06-08 16:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
CC| |fxcoudert at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I take it this one can be closed :)
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-06-08 16:44 ` fxcoudert at gcc dot gnu.org
@ 2014-06-10 10:21 ` jb at gcc dot gnu.org
2014-07-14 22:03 ` townsend at astro dot wisc.edu
` (4 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-06-10 10:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-06-10 10:21 ` jb at gcc dot gnu.org
@ 2014-07-14 22:03 ` townsend at astro dot wisc.edu
2014-07-15 6:09 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: townsend at astro dot wisc.edu @ 2014-07-14 22:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Rich Townsend <townsend at astro dot wisc.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |townsend at astro dot wisc.edu
--- Comment #6 from Rich Townsend <townsend at astro dot wisc.edu> ---
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-07-14 22:03 ` townsend at astro dot wisc.edu
@ 2014-07-15 6:09 ` jb at gcc dot gnu.org
2014-11-13 12:05 ` jb at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-07-15 6:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2014-07-15 6:09 ` jb at gcc dot gnu.org
@ 2014-11-13 12:05 ` jb at gcc dot gnu.org
2014-11-13 12:07 ` jb at gcc dot gnu.org
2014-11-16 1:58 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-11-13 12:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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 <jb@gcc.gnu.org>
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2014-11-13 12:05 ` jb at gcc dot gnu.org
@ 2014-11-13 12:07 ` jb at gcc dot gnu.org
2014-11-16 1:58 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-11-13 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Fixed on trunk, closing.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libfortran/60324] Handle arbitrarily long path names
[not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2014-11-13 12:07 ` jb at gcc dot gnu.org
@ 2014-11-16 1:58 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 10+ messages in thread
From: jb at gcc dot gnu.org @ 2014-11-16 1:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #10 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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 <jb@gcc.gnu.org>
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
^ permalink raw reply [flat|nested] 10+ messages in thread