public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/54878] New: libgfortran issues found by the Coverity scanner
@ 2012-10-09 20:55 burnus at gcc dot gnu.org
2012-10-10 18:42 ` [Bug fortran/54878] " burnus at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-10-09 20:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54878
Bug #: 54878
Summary: libgfortran issues found by the Coverity scanner
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: burnus@gcc.gnu.org
CC: jb@gcc.gnu.org, tkoenig@gcc.gnu.org
Sister bug to the FE PR 54599. The coverity scanner found the following
(potential) issues in libgfortran.
a) io/unix.c: Before calling mkstemps, one should set the umask - otherwise,
one might create a world-readable file in /tmp. As the Linux man page put it:
The old behavior of creating a file with mode 0666 may be a security
risk, especially since other UNIX flavors use 0600, and somebody
might overlook this detail when porting programs.
More generally, the POSIX specification of mkstemp() does not say
anything about file modes, so the application should make sure its
file mode creation mask (see umask(2)) is set appropriately before
calling mkstemp() (and mkostemp()).
b) io/unix.c: In fd_to_stream: Return value not checked for
fstat (fd, &statbuf);
c) io/unit.c's filename_from_unit
At (17): Calling function "unpack_filename(char *, char const *, int)"
without checking return value (as is done elsewhere 10 out of 12 times).
At (18): No check of the return value of "unpack_filename(filename, u->file,
u->file_len)".
784 unpack_filename (filename, u->file, u->file_len);
785 return filename;
d) generated/iall_i1.c: Unreachable code:
220 len = GFC_DESCRIPTOR_EXTENT(array,dim);
221 if (len <= 0)
222 return;
...
326 if (len <= 0)
327 *dest = 0;
e) runtime/bounds.c: index_type count_0
At (3): Comparing "base" to null implies that "base" might be null.
228 if (base)
229 base = GFOR_POINTER_TO_L1 (base, kind);
...
CID 732652 (#1 of 1): Dereference after null check (FORWARD_NULL)At (10):
Dereferencing null pointer "base".
248 if (*base)
249 result ++;
f) io/list_read.c: Unreachable code in nml_query:
2432 p = write_block (dtp, endlen + 3);
2433 goto query_return;
2434 memcpy (p, &nmlend, endlen + 3); /* <<< UNREACHABLE */
Additionally/Hence: the result "p" is never used.
g) io/intrinsics.c
CID 732515 (#1 of 1): Unchecked return value (CHECKED_RETURN)At (3): Calling
function "sseek(stream *, gfc_offset, int)" without checking return value (as
is done elsewhere 21 out of 26 times).
(Also not checked in io/file_pos.c's st_backspace.)
262 gf_ftell (int unit)
...
269 sseek (u->s, pos, SEEK_CUR);
h) io/inquire.c: inquire_via_unit
47 *iqp->exist = (iqp->common.unit >= 0
48 && iqp->common.unit <= GFC_INTEGER_4_HUGE);
The latter is ways true as common.unit is of type GFC_INTEGER_4.
And some more.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/54878] libgfortran issues found by the Coverity scanner
2012-10-09 20:55 [Bug fortran/54878] New: libgfortran issues found by the Coverity scanner burnus at gcc dot gnu.org
@ 2012-10-10 18:42 ` burnus at gcc dot gnu.org
2014-12-21 12:37 ` dominiq at lps dot ens.fr
2021-12-16 18:23 ` [Bug libfortran/54878] " fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-10-10 18:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54878
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-10-10 18:42:39 UTC ---
Author: burnus
Date: Wed Oct 10 18:42:34 2012
New Revision: 192325
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192325
Log:
2012-10-10 Tobias Burnus <burnus@net-b.de>
PR fortran/54878
* io/unix.c (tempfile_open): Set umask before calling mkstemp.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/54878] libgfortran issues found by the Coverity scanner
2012-10-09 20:55 [Bug fortran/54878] New: libgfortran issues found by the Coverity scanner burnus at gcc dot gnu.org
2012-10-10 18:42 ` [Bug fortran/54878] " burnus at gcc dot gnu.org
@ 2014-12-21 12:37 ` dominiq at lps dot ens.fr
2021-12-16 18:23 ` [Bug libfortran/54878] " fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-12-21 12:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54878
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-21
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
At least (d) and (f) are gone while others are still there at r218995.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libfortran/54878] libgfortran issues found by the Coverity scanner
2012-10-09 20:55 [Bug fortran/54878] New: libgfortran issues found by the Coverity scanner burnus at gcc dot gnu.org
2012-10-10 18:42 ` [Bug fortran/54878] " burnus at gcc dot gnu.org
2014-12-21 12:37 ` dominiq at lps dot ens.fr
@ 2021-12-16 18:23 ` fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2021-12-16 18:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54878
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The followings don't exist anymore in the current code: a, b, c, h.
d) is still present, but it is for generated code, due to the very generic way
the code is being generated. Not an issue.
e) is still present. I think it's guaranteed that base is not NULL, but someone
might want to double-check the logic there.
f) was fixed in:
commit a0b012be6aef65bd11107f8dac814c3ac36f95d0
Author: Tobias Burnus <burnus@net-b.de>
Date: 2013-03-29 10:32:57 +0100
g) Not sure why it's considered bad practice to ignore the return value of a
function call. In some cases, it's not a problem.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-12-16 18:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-09 20:55 [Bug fortran/54878] New: libgfortran issues found by the Coverity scanner burnus at gcc dot gnu.org
2012-10-10 18:42 ` [Bug fortran/54878] " burnus at gcc dot gnu.org
2014-12-21 12:37 ` dominiq at lps dot ens.fr
2021-12-16 18:23 ` [Bug libfortran/54878] " fxcoudert at gcc dot gnu.org
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).