* [PATCH,Fortran] Fix libgfortran/io/close.c for !HAVE_UNLINK_OPEN_FILE
@ 2018-10-02 11:08 Gerald Pfeifer
2018-10-02 15:55 ` Janne Blomqvist
0 siblings, 1 reply; 2+ messages in thread
From: Gerald Pfeifer @ 2018-10-02 11:08 UTC (permalink / raw)
To: fortran, gcc-patches, Janne Blomqvist
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Revision r215307 | jb | 2014-09-16 23:40:28 +0200 (Di, 16 Sep 2014)
PR libfortran/62768 Handle filenames with embedded null characters.
:
made the changes like the following to libgfortran/io/close.c
#if !HAVE_UNLINK_OPEN_FILE
- path = fc_strdup (u->file, u->file_len);
+ path = strdup (u->filename);
#endif
One of our users now reported this build failure for a system where
(for whatever reason) HAVE_UNLINK_OPEN_FILE is not defined:
.../GCC-HEAD/libgfortran/io/close.c:94:11: error: implicit declaration of function Β‘strdupΒ’
94 | path = strdup (u->filename);
| ^~~~~~
By #undef-ining HAVE_UNLINK_OPEN_FILE beetween the #include "..." and
#include <...> statements in libgfortran/io/close.c I could reproduce
this on FreeBSD 11/i386.
And I could validate the fix below, both with and without that #undef
in place.
Tested on i386-unknown-freebsd11.1.
Okay to commit?
I'd also like to apply this to older release branches (down to GCC 6)
since it is obviously broken and the fix appears straightforward. If
approved, I'm thinking to wait about a week or two before making each
step backwards (from HEAD to 8, 8 to 7, and 7 to 6).
Gerald
2018-10-02 Gerald Pfeifer <gerald@pfeifer.com>
* io/close.c [!HAVE_UNLINK_OPEN_FILE]: Include <string.h>.
Index: libgfortran/io/close.c
===================================================================
--- libgfortran/io/close.c (revision 264772)
+++ libgfortran/io/close.c (working copy)
@@ -26,6 +26,9 @@ see the files COPYING3 and COPYING.RUNTIME respect
#include "unix.h"
#include "async.h"
#include <limits.h>
+#if !HAVE_UNLINK_OPEN_FILE
+#include <string.h>
+#endif
typedef enum
{ CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH,Fortran] Fix libgfortran/io/close.c for !HAVE_UNLINK_OPEN_FILE
2018-10-02 11:08 [PATCH,Fortran] Fix libgfortran/io/close.c for !HAVE_UNLINK_OPEN_FILE Gerald Pfeifer
@ 2018-10-02 15:55 ` Janne Blomqvist
0 siblings, 0 replies; 2+ messages in thread
From: Janne Blomqvist @ 2018-10-02 15:55 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Fortran List, GCC Patches, Janne Blomqvist
On Tue, Oct 2, 2018 at 2:08 PM Gerald Pfeifer <gerald@pfeifer.com> wrote:
> Revision r215307 | jb | 2014-09-16 23:40:28 +0200 (Di, 16 Sep 2014)
>
> PR libfortran/62768 Handle filenames with embedded null characters.
> :
>
> made the changes like the following to libgfortran/io/close.c
>
> #if !HAVE_UNLINK_OPEN_FILE
> - path = fc_strdup (u->file, u->file_len);
> + path = strdup (u->filename);
> #endif
>
>
> One of our users now reported this build failure for a system where
> (for whatever reason) HAVE_UNLINK_OPEN_FILE is not defined:
>
> .../GCC-HEAD/libgfortran/io/close.c:94:11: error: implicit declaration
> of function ‘strdup’
> 94 | path = strdup (u->filename);
> | ^~~~~~
>
>
> By #undef-ining HAVE_UNLINK_OPEN_FILE beetween the #include "..." and
> #include <...> statements in libgfortran/io/close.c I could reproduce
> this on FreeBSD 11/i386.
>
> And I could validate the fix below, both with and without that #undef
> in place.
>
>
> Tested on i386-unknown-freebsd11.1.
>
>
> Okay to commit?
>
> I'd also like to apply this to older release branches (down to GCC 6)
> since it is obviously broken and the fix appears straightforward. If
> approved, I'm thinking to wait about a week or two before making each
> step backwards (from HEAD to 8, 8 to 7, and 7 to 6).
>
> Gerald
>
Ok, thanks!
--
Janne Blomqvist
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-10-02 15:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-02 11:08 [PATCH,Fortran] Fix libgfortran/io/close.c for !HAVE_UNLINK_OPEN_FILE Gerald Pfeifer
2018-10-02 15:55 ` Janne Blomqvist
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).