[Patch] libfortran: Fix execute_command_line for Windows
Reported by nightstrike, who also tested this patch. On Windows, we call system() which works as described at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170 Namely, it only fails with "-1" if the command interpreter could not be started. Otherwise, it has the return value. (Same on Linux.) On POSIX systems, 'sh' calls exit(127) or _exit(127) if it cannot execute the program of the passed string, as documented. Cf. https://www.unix.com/man-page/posix/3p/system/ Thus, the question is what happens on Windows. Our experiments, several webpages (like stackoverflow) and the source code of WINE for cmd.exe indicate that Windows returns 9009 in that case. See for instance https://github.com/wine-mirror/wine/blob/master/programs/cmd/wcmdmain.c#L1262-L1269 Thus, we now do likewise. The code is for MINGW; Cygwin does not set that that var and is likely to use return values closer to POSIX. OK for mainline? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 libfortran: Fix execute_command_line for Windows On Windows, 'system' is called - that fails with -1 if the command interpreter could not be started; on POSIX systems, if the child process could not be started by the shell, exit(127)/_exit(127) is called/returned. On Windows, cmd.exe (and also the PowerShell) return errorlevel 9009. libgfortran/ChangeLog: * intrinsics/execute_command_line.c (execute_command_line): On Windows, regard system()'s return value of 9009 as EXEC_INVALIDCOMMAND. diff --git a/libgfortran/intrinsics/execute_command_line.c b/libgfortran/intrinsics/execute_command_line.c index 305f067d973..0d1688400c2 100644 --- a/libgfortran/intrinsics/execute_command_line.c +++ b/libgfortran/intrinsics/execute_command_line.c @@ -142,10 +142,15 @@ execute_command_line (const char *command, bool wait, int *exitstat, #endif else if (res == 127 || res == 126 #if defined(WEXITSTATUS) && defined(WIFEXITED) || (WIFEXITED(res) && WEXITSTATUS(res) == 127) || (WIFEXITED(res) && WEXITSTATUS(res) == 126) +#endif +#ifdef __MINGW32__ + /* cmd.exe sets the errorlevel to 9009, + if the command could not be executed. */ + || res == 9009 #endif ) /* Shell return codes 126 and 127 mean that the command line could not be executed for various reasons. */ set_cmdstat (cmdstat, EXEC_INVALIDCOMMAND);
Re: [Patch] libfortran: Fix execute_command_line for Windows
Hi Tobias, Am 18.01.23 um 16:42 schrieb Tobias Burnus: Reported by nightstrike, who also tested this patch. On Windows, we call system() which works as described at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170 Namely, it only fails with "-1" if the command interpreter could not be started. Otherwise, it has the return value. (Same on Linux.) On POSIX systems, 'sh' calls exit(127) or _exit(127) if it cannot execute the program of the passed string, as documented. Cf. https://www.unix.com/man-page/posix/3p/system/ Thus, the question is what happens on Windows. Our experiments, several webpages (like stackoverflow) and the source code of WINE for cmd.exe indicate that Windows returns 9009 in that case. See for instance https://github.com/wine-mirror/wine/blob/master/programs/cmd/wcmdmain.c#L1262-L1269 Thus, we now do likewise. The code is for MINGW; Cygwin does not set that that var and is likely to use return values closer to POSIX. I don't use Windows, but this LGTM. OK for mainline? Yes, and thanks for the patch! Harald Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[PATCH] Fortran: error recovery for invalid CLASS component [PR108434]
Dear all,
I intend to commit the attached obvious fix for a NULL pointer dereference
within the next 24h unless there are comment or objections.
The patch has been checked with valgrind that it prevents invalid reads
for the testcase, and it is certainly safe.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From e240637f6c2e2605a8424538bee885d899507506 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 18 Jan 2023 22:13:29 +0100
Subject: [PATCH] Fortran: error recovery for invalid CLASS component
[PR108434]
gcc/fortran/ChangeLog:
PR fortran/108434
* expr.cc (class_allocatable): Prevent NULL pointer dereference
or invalid read.
(class_pointer): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/108434
* gfortran.dg/pr108434.f90: New test.
---
gcc/fortran/expr.cc| 4 ++--
gcc/testsuite/gfortran.dg/pr108434.f90 | 11 +++
2 files changed, 13 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr108434.f90
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 5ec369c9cd8..3036b1be60f 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -4996,14 +4996,14 @@ get_union_initializer (gfc_symbol *union_type, gfc_component **map_p)
static bool
class_allocatable (gfc_component *comp)
{
- return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+ return comp->ts.type == BT_CLASS && comp->attr.class_ok && CLASS_DATA (comp)
&& CLASS_DATA (comp)->attr.allocatable;
}
static bool
class_pointer (gfc_component *comp)
{
- return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+ return comp->ts.type == BT_CLASS && comp->attr.class_ok && CLASS_DATA (comp)
&& CLASS_DATA (comp)->attr.pointer;
}
diff --git a/gcc/testsuite/gfortran.dg/pr108434.f90 b/gcc/testsuite/gfortran.dg/pr108434.f90
new file mode 100644
index 000..e1768a57574
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108434.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/108434 - ICE in class_allocatable
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ class(c), pointer :: a(2) ! { dg-error "must have a deferred shape" }
+ end type t
+ class(t), allocatable :: x
+ class(t), pointer :: y
+end
--
2.35.3
Re: [Patch] libfortran: Fix execute_command_line for Windows
On 1/18/23 7:42 AM, Tobias Burnus wrote: Reported by nightstrike, who also tested this patch. On Windows, we call system() which works as described at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170 Namely, it only fails with "-1" if the command interpreter could not be started. Otherwise, it has the return value. (Same on Linux.) On POSIX systems, 'sh' calls exit(127) or _exit(127) if it cannot execute the program of the passed string, as documented. Cf. https://www.unix.com/man-page/posix/3p/system/ Thus, the question is what happens on Windows. Our experiments, several webpages (like stackoverflow) and the source code of WINE for cmd.exe indicate that Windows returns 9009 in that case. See for instance https://github.com/wine-mirror/wine/blob/master/programs/cmd/wcmdmain.c#L1262-L1269 Thus, we now do likewise. The code is for MINGW; Cygwin does not set that that var and is likely to use return values closer to POSIX. OK for mainline? Tobias OK, thanks fir fix. Jerry
Re: Team Collaboration Considerations
On 12/26/22 13:19, NightStrike via Fortran wrote: > On Tue, Dec 13, 2022, 03:10 Janne Blomqvist via Fortran > wrote: > >> But in general, yes, I do think IRC is showing its age in an >> increasingly multi-device and mobile world. >> > > Tools like irccloud help here. I guess that doesn't qualify as open source > though. > >> Might a GSOC project examining community health be something that could produce useful recommendations on improving developer efficiency and getting new contributors? The project can also produce a monitoring system that fits the GCC workflow. A chat tool is helpful (Rust uses Zulip https://gcc-rust.zulipchat.com), but it seems understanding how the project develops and keeping track of relevant information are greater obstacles. The GCC workflows is quite different from other open source projects being primarily email based and not using a bug tracker. Email does work well, and has been adapted in Sourcehut, but they have had to introduce a tutorial: https://git-send-email.io/
