[Bug fortran/54878] New: libgfortran issues found by the Coverity scanner

[Bug fortran/54878] New: libgfortran issues found by the Coverity scanner

[burnus at gcc dot gnu.org]

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.

[Bug fortran/54878] libgfortran issues found by the Coverity scanner

[burnus at gcc dot gnu.org]

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

[Bug fortran/54878] libgfortran issues found by the Coverity scanner

[dominiq at lps dot ens.fr]

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.

[Bug libfortran/54878] libgfortran issues found by the Coverity scanner

[fxcoudert at gcc dot gnu.org]

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.