[llvm-bugs] [Bug 33240] New: Enhancement request: __attribute__((warn_untested_result))

via llvm-bugs llvm-bugs at lists.llvm.org
Tue May 30 19:49:40 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=33240

            Bug ID: 33240
           Summary: Enhancement request:
                    __attribute__((warn_untested_result))
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: joe at perches.com
                CC: llvm-bugs at lists.llvm.org

Duplicate request submitted to gcc

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

A possibly useful addition similar to:

__attribute__((warn_unused_result))

might be

__attribute__((warn_untested_result))

for things like allocation failures that
are not verified before use.

For instance:

    void *malloc(size_t size);

could become

    void * __attribute__((warn_untested_result)) malloc(size_t size)

so that

    #include <stdlib.h>

    struct foo {
            int bar;
    };

    struct foo *alloc_foo(void)
    {
            struct foo *baz = malloc(sizeof(struct foo));
            baz->bar = 1;
            return baz;
    }

The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.

    struct foo *alloc_foo(void)
    {
            struct foo *baz = malloc(sizeof(struct foo));
            if (baz) baz->bar = 1;
            return baz;
    }

This variant would not emit a warning.

Similarly, alloc_foo could use that new attribute.

Martin Sebor also mentioned that non-allocation
functions like fopen could also use this __attribute__
mechanism.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170531/52d21dff/attachment.html>


More information about the llvm-bugs mailing list