[Bf-committers] bugs?

Campbell Barton ideasman42 at gmail.com
Fri Feb 11 06:52:54 CET 2011


I've been building Clang/LLVM from SVN for a while and tried to fix
these warnings/bugs and we have blender down to 670 warnings from
1153.
Old reports: http://www.graphicall.org/ftp/ideasman42/2011-01-07-2/

If anyone on Linux is interested, heres how I setup blender/clang.
http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang

There were certainly cases where functions ran for no reason and could
be commented/removed but I think these are all resolved now.
The reason I didn't continue to clear the dead assignment warnings is
it would do more harm then good IMHO.

Example
----------
static void stats_background(void *UNUSED(arg), RenderStats *rs)
{
    char str[400], *spos= str;
 --- snip ---
    spos+= sprintf(spos, "Fra:%d Mem:%.2fM (%.2fM, peak %.2fM) ",
rs->cfra,megs_used_memory, mmap_used_memory, megs_peak_memory);

    if(rs->curfield)
        spos+= sprintf(spos, "Field %d ", rs->curfield);
    if(rs->curblur)
        spos+= sprintf(spos, "Blur %d ", rs->curblur);

    if(rs->infostr) {
        spos+= sprintf(spos, "| %s", rs->infostr);
    }
    else {
        if(rs->tothalo)
            spos+= sprintf(spos, "Sce: %s Ve:%d Fa:%d Ha:%d La:%d",
rs->scenename, rs->totvert, rs->totface, rs->tothalo, rs->totlamp);
        else
            spos+= sprintf(spos, "Sce: %s Ve:%d Fa:%d La:%d",
rs->scenename, rs->totvert, rs->totface, rs->totlamp);
    }
    printf("%s\n", str);
}
----------

You can tell that the last 3 'spos +=' are dead assignments, but if
these are removed, a developer might add a new string later and forget
to add one of them back.
Same goes for 'yofs += ' with many interface functions.

In some cases I commented the assignment, eg:
        /*spos+=*/ sprintf(spos, "| %s", rs->infostr);

But this is only good if the variable its self is commented otherwise
it could be used later where the developer needs to remember to
uncomment the assignment which isn't always obvious.

To quiet Clang's dead assignment warnings we could do this at the end
of functions...
----------
    (void)spos;
}
----------

It would be nice to quiet the warnings so we know all warnings are
_real_ problems and real bugs don't get mixed up with harmless reports
but this also adds cruft which is why I didn't go ahead with it.

If other devs think its worth trying to get even fewer warnings we
could in the same way its nice to have 0 compiler warnings, but at
this point I feel we're getting diminishing returns for making such
small changes.

- Campbell

On Fri, Feb 11, 2011 at 1:10 AM, Tom M <letterrip at gmail.com> wrote:
> When using CLangs static checker on Blender,
>
> there are a large number of 'dead stores' - variables that are
> assigned a value, but the variable is never used.
>
> Thus these are items that either had functionality at one point, but
> no longer do.  Or are intended to have functionality that is not yet
> in use.
>
> Almost none of them are commented so it isn't readily determined which
> of the two cases it is.  There are about 200 instances of dead stores
> in the code.
>
> Here are some examples (filename, then variable name, and the line
> number).  In my view they should either be commented, commented out or
> deleted.
>
> Having them in the code can make it confusing to read since you try
> and track where and how the variable is used.
>
> anim_channel_defines.c
> type            - 2614 ok (unneeded ++)
> enabled         - 3121
> text            - 3241
> offset          - 3266, 3271
>
> anim_channels_edit.c
> prevLevel       - 490
> ymin            - 1766, 1770
>
> fmodifier_ui.c
> col             - 117
> row             - 523, 541
>
> keyframes_draw.c
> abp             - 363
>
> drawgpencil.c
> actlay          - 540
>
> gpencil_paint.c
> ok              - 1356
>
> interface.c
> okwidth - 2087
> str             - 2193
>
> interface_handlers.c
> retval          - 1798
> softmin - 2237
> softmax - 2238
> temp            - 2399
> screen_my       - 2424
> click           - 2786
> offsx           - 2380
> offsy           - 2381
> changed - 3480, 3511
> dx              - 3603, 3686
> yfac            - 3695
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list