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

Charles Blake <charlechaud at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |charlechaud at gmail dot com

--- Comment #11 from Charles Blake <charlechaud at gmail dot com> ---
Here is another example (no external includes/etc.):

typedef long unsigned int size_t;

extern void *malloc (size_t __size) __attribute__ ((__nothrow__ , __leaf__))
__attribute__ ((__malloc__))
     __attribute__ ((__alloc_size__ (1))) __attribute__
((__warn_unused_result__));

extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));

typedef struct { long count, flags; } Foo;

Foo *G(Foo *x, long flags, int unused) {
    if (x) { // originally a file descriptor
        x->count = 0; flags = 0;
    } else {
        if (!(x = (Foo *)malloc(sizeof *x))) return (Foo *)0;
        flags = 1;
    }
    x->flags = flags;
    return x;
}

Foo *F(Foo *x, long flags) {
    if (x) { // originally a pathname path
        x->count = 0; flags = 0;
    } else {
        if (!(x = (Foo *)malloc(sizeof *x))) return (Foo *)0;
        flags = 1;
    }
    x->flags = flags;
    return G(x, flags, 123);
}

void release(Foo *x) {
    if (x && x->flags) free(x);
}

int main(void) {
    Foo x;
    if (F(&x, 0))
        release(&x);
    return 0;
}

In the above, variations due to compiler optimization levels make it even more
confusing: -O1 does not warn, -O2 does warn, -O3 again does not warn (on both
gcc-12.3 and gcc-13.2 on Gentoo Linux, anyway). O3 optimizes the whole main
away.  clang never warns on this at any -O level, nor with clang --analyze.

What is particularly bad about this warning is that AFAICT there is no way to
massage the code to reliably silence it while also preserving the intended
effect.  Now it's even on by default.  This actively discourages an otherwise
clean arrangement in the C programming language when working with anyone else
who takes warns too seriously.  Any such warning should have "may be" language
not language that sounds like the compiler has "proved an actuality".

Might the same argument apply to many warnings?  Maybe.  Two words is not so
bad, though.  Other warns may have workarounds like annotations to silence them
reliably without sacrificing functionality.  Maybe I'm missing one here?

Reply via email to