public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions
@ 2015-08-02  0:07 msebor at gcc dot gnu.org
  2015-08-02  3:11 ` [Bug c/67093] " pinskia at gcc dot gnu.org
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-02  0:07 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

            Bug ID: 67093
           Summary: incorrect -Wnonnull text for execl family of functions
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the execl function is invoked with a null second argument, GCC issues two
warnings, one saying "null argument where non-null required" and another "not
enough variable arguments to fit a sentinel."

The text of the first warning is incorrect.  POSIX doesn't require that arg0 be
non-null, it only suggests that it point to a filename string.  C also doesn't
require that argv[0] be non-null.  The text of the second warning is
misleading.  However, since many programs assume that argv[0] is non-null, a
warning is helpful, but the text should be adjusted so as not to imply stronger
requirements than POSIX imposes on strictly conforming programs.  For instance,
the wording could be changed to say "null argument where non-null usually
expected."

$ cat t.c && ~/bin/powerpc64/bin/gcc -Wall t.c && ./a.out
#include <assert.h>
#include <stdio.h>
#include <unistd.h>

int main (int argc, char *argv[])
{
    if (0 < argc)
        execl (argv [0], (void*)0);

    printf ("argv[argc] = %s\n", argv [argc] ? argv [argc] : "null");

    assert (0 == argv [argc]);

    return 0;
}
t.c: In function ‘main’:
t.c:8:9: warning: null argument where non-null required (argument 2)
[-Wnonnull]
         execl (argv [0], (void*)0);
         ^
t.c:8:9: warning: not enough variable arguments to fit a sentinel [-Wformat=]
argv[argc] = null
>From gcc-bugs-return-493883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 02 01:18:29 2015
Return-Path: <gcc-bugs-return-493883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126140 invoked by alias); 2 Aug 2015 01:18:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126029 invoked by uid 55); 2 Aug 2015 01:18:17 -0000
From: "ctice at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
Date: Sun, 02 Aug 2015 01:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ctice at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66521-4-6Bri9nchBn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66521-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66521-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00025.txt.bz2
Content-length: 2410

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf521

--- Comment #10 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Sun Aug  2 01:17:39 2015
New Revision: 226471

URL: https://gcc.gnu.org/viewcvs?rev"6471&root=gcc&view=rev
Log:
Fix PR 66521

libvtv/ChangeLog

2015-08-01  Caroline Tice  <cmtice@google.com>

        PR 66521
        * Makefile.am: Update to match latest tree.
        * Makefile.in: Regenerate.
        * testsuite/lib/libvtv: Brought up to date.
        * vtv_malloc.cc (VTV_DEBUG): Update function call to match renamed
        function (old bug!).
        * vtv_rts.cc (debug_functions, debug_init, debug_verify_vtable): Update
        initializations to work correctly with VTV_DEBUG defined.

gcc/ChangeLog:

2015-08-01  Caroline Tice  <cmtice@google.com>

        PR 66521
        * vtable-verify.c (vtbl_mangled_name_types, vtbl_mangled_name_ids): New
        global variables.
        (vtbl_find_mangled_name):  New function.
        (vtbl_register_mangled_name):  New function.
        (vtbl_map_get_node):  If DECL_ASSEMBLER_NAME is "<anon>", look up
        mangled name in mangled name vectors.
        (find_or_create_vtbl_map_node):  Ditto.
        (var_is_used_for_virtual_call_p):  Add recursion_depth parameter;
        update recursion_depth on function entry; pass it to every recursive
        call; automatically exit if depth > 25 (give up looking at that point).
        (verify_bb_vtables):  Initialize recursion_depth and pass it to
        var_is_used_for_virtual_call_p.
        * vtable-verify.h (vtbl_mangbled_name_types, vtbl_mangled_name_ids):
New
        global variable decls.
        (vtbl_register_mangled_name): New extern function decl.

gcc/cp/ChangeLog:
2015-08-01  Caroline Tice  <cmtice@google.com>

        PR 66521
        * mangle.c : Add vtable-verify.h to include files.
        (get_mangled_vtable_map_var_name):  If the DECL_ASSEMBLER_NAME
        is "<anon>" get the real mangled name for the class instead, and
        also store the real mangled name in a vector for use later.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/mangle.c
    trunk/gcc/vtable-verify.c
    trunk/gcc/vtable-verify.h
    trunk/libvtv/ChangeLog
    trunk/libvtv/testsuite/Makefile.am
    trunk/libvtv/testsuite/Makefile.in
    trunk/libvtv/testsuite/lib/libvtv.exp
    trunk/libvtv/vtv_malloc.cc
    trunk/libvtv/vtv_rts.cc


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
@ 2015-08-02  3:11 ` pinskia at gcc dot gnu.org
  2015-08-02 15:38 ` msebor at gcc dot gnu.org
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-08-02  3:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
POSIX says:
The argument arg0 should point to a filename string that is associated with the
process being started by one of the exec functions.

At least from
http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html (which I
assume is the POSIX documentation).

The question here is what is the definition of should in this context.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
  2015-08-02  3:11 ` [Bug c/67093] " pinskia at gcc dot gnu.org
@ 2015-08-02 15:38 ` msebor at gcc dot gnu.org
  2015-08-03  2:50 ` pinskia at gcc dot gnu.org
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-02 15:38 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Yes, that's the latest POSIX spec.  The term "should" is defined in section 1.5
Terminology as:

  ...
  For an application, describes a feature or behavior that is recommended
 programming practice for optimum portability.

(http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html#tag_01_05_06)


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
  2015-08-02  3:11 ` [Bug c/67093] " pinskia at gcc dot gnu.org
  2015-08-02 15:38 ` msebor at gcc dot gnu.org
@ 2015-08-03  2:50 ` pinskia at gcc dot gnu.org
  2015-08-03 14:58 ` msebor at gcc dot gnu.org
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-08-03  2:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And right before the quote you gave:
"An application that relies on such a feature or behavior cannot be assured to
be portable across conforming implementations."

So this might not be a full requirement of POSIX, it is not a portable to do
it.  So GCC warns about this case.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2015-08-03  2:50 ` pinskia at gcc dot gnu.org
@ 2015-08-03 14:58 ` msebor at gcc dot gnu.org
  2015-08-03 15:55 ` redi at gcc dot gnu.org
  2015-08-03 16:15 ` msebor at gcc dot gnu.org
  5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-03 14:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The requirements on execl() and main() are specified in sufficient detail to
guarantee that a program that call execl("/some/other/program", (char*)0) is
portable across all conforming implementations so long as /some/other/program
doesn't assume that argv[0] is non-null.

Issuing a warning in this case is useful because programs often do make this
assumption (including some utilities that are part of an implementation --
e.g., /bin/echo on Linux, see below).  That is why applications that assume
that it's safe to pass null as arg0 is safe "cannot be assured to be portable
across conforming implementations."  (I.e., the utilities themselves aren't
strictly conforming C programs.)

What this issue points out is not that the warning is wrong but that its text
isn't strictly speaking correct: passing a non-null arg0 is not required, only
recommended.

$ cat t.c && gcc t.c && ./a.out 
#include <unistd.h>

int main (void) {
    return execl ("/bin/echo", (char*)0);
}
A NULL argv[0] was passed through an exec system call.
Aborted (core dumped)

This is a C conformance bug in /bin/echo since there is no requirement that
argv[0] be non-null.

Why do I point this out?  Because the use of the word "required" in the text of
the warning perpetuates the widespread misconception that argv[0] is guaranteed
to be non-null.  The programs that should be fixed are those that make this
assumption.   Calling execl with a non-null arg0 just works around the bug.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2015-08-03 14:58 ` msebor at gcc dot gnu.org
@ 2015-08-03 15:55 ` redi at gcc dot gnu.org
  2015-08-03 16:15 ` msebor at gcc dot gnu.org
  5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2015-08-03 15:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Surely GCC only warns here because glibc adds the attribute to the execl
declaration, so the bug is in glibc.

GCC interprets the nonnull attribute to mean the argument *must* be non-null,
and even optimises based on that assumption. So the attribute should not be
used for recommendations, only requirements.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug c/67093] incorrect -Wnonnull text for execl family of functions
  2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2015-08-03 15:55 ` redi at gcc dot gnu.org
@ 2015-08-03 16:15 ` msebor at gcc dot gnu.org
  5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2015-08-03 16:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67093

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
execl is a GCC builtin and GCC issues the -Wformat warning regardless of its
declaration:

$ cat t.c && ~/bin/gcc-5.1.0/bin/gcc -Wall t.c
extern int execl (const char*, const char*, ...);

int main (void) {
    return execl ("/bin/echo", (char*)0);
}
t.c: In function ‘main’:
t.c:4:5: warning: not enough variable arguments to fit a sentinel [-Wformat=]
     return execl ("/bin/echo", (char*)0);
     ^

You're right though that the -Wnonnull warning is due to the nonnull attribute.
>From gcc-bugs-return-493960-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 03 16:26:52 2015
Return-Path: <gcc-bugs-return-493960-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 79444 invoked by alias); 3 Aug 2015 16:26:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 79031 invoked by uid 55); 3 Aug 2015 16:26:47 -0000
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
Date: Mon, 03 Aug 2015 16:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66314-4-XGTklVRkax@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66314-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66314-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00102.txt.bz2
Content-length: 826

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf314

--- Comment #12 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Mon Aug  3 16:26:13 2015
New Revision: 226516

URL: https://gcc.gnu.org/viewcvs?rev"6516&root=gcc&view=rev
Log:
        PR middle-end/66314
        PR gcov-profile/66899
        * tree-ssa-threadupdate.c (mark_threaded_blocks): Correctly
        iterate over the jump threading paths when an element in the
        jump threading paths array is eliminated.

        PR middle-end/66314
        PR gcov-profile/66899
        * gcc.dg/pr66899.c: New test.
        * gcc.dg/pr66314.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr66314.c
    trunk/gcc/testsuite/gcc.dg/pr66899.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-threadupdate.c


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-08-03 16:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-02  0:07 [Bug c/67093] New: incorrect -Wnonnull text for execl family of functions msebor at gcc dot gnu.org
2015-08-02  3:11 ` [Bug c/67093] " pinskia at gcc dot gnu.org
2015-08-02 15:38 ` msebor at gcc dot gnu.org
2015-08-03  2:50 ` pinskia at gcc dot gnu.org
2015-08-03 14:58 ` msebor at gcc dot gnu.org
2015-08-03 15:55 ` redi at gcc dot gnu.org
2015-08-03 16:15 ` msebor 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).