POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#265 - Warnings from clang that might need consideration

Attached to Project: POV-Ray
Opened by Grimbert Jérôme (Le_Forgeron) - Friday, 11 January 2013, 15:14 GMT
Last edited by William F Pokorny (wfpokorny) - Friday, 25 November 2016, 15:48 GMT
Task Type Possible Bug
Category Backend → Other
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 RC6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Compiling the sources with clang instead of g++ (on ubuntu 12.10 with boost 1.50)

./configure COMPILED_BY=”your name here <also@email>” LIBS=-lboost_system –disable-io-restrictions CC=clang CXX=clang

there is a few warnings that catch the eyes (and other as well that I dismiss so far, such as cases not covered in switch and empty body in if, or extraneous parentheses in tests):

support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
support/randomsequences.cpp:974:40: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<int>::PrecomputedNumberGenerator' requested here
        SeedableIntGeneratorPtr generator(new PrecomputedIntGenerator(factory, count));
                                              ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:984:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<double>::PrecomputedNumberGenerator' requested here
        SeedableDoubleGeneratorPtr generator(new PrecomputedDoubleGenerator(factory, count));
                                                 ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1011:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector3d>::PrecomputedNumberGenerator' requested here
                return SequentialVectorGeneratorPtr(new PrecomputedVectorGenerator(factory, count));
                                                        ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1056:45: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector2d>::PrecomputedNumberGenerator' requested here
                return SequentialVector2dGeneratorPtr(new PrecomputedVector2dGenerator(factory, count));

Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).

                           
             povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handleroo;
                        ^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handler;
                        ^

Maybe just a missing keyword (virtual) in the header file ? Or is it harder ?


shelloutprocessing.cpp:260:28: warning: expression result unused [-Wunused-value]
        for (s = str.c_str(); *s; *s++)
                                  ^~~~

Why “*s++” ? why not just “s++” ?

renderfrontend.cpp:1165:57: warning: trigraph ignored [-Wtrigraphs]
                                        default:                                    t = "(???)";                            break;
 

I guess it’s not an intended trigraph. Might nevertheless perturb some compiler/result.

This task depends upon

Closed by  William F Pokorny (wfpokorny)
Friday, 25 November 2016, 15:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  In a clang compile of 3.7.1 master Nov 23, 2016 none of the warnings here are now present; though, there are a few other minor ones.

We are today regularly doing clang compiles and I suggest we address new clang warnings on github or in code as we see them.
Comment by Christoph Lipka (clipka) - Friday, 11 January 2013, 18:18 GMT

Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).

Oops, yes, indeed. No harm done though, as startIndex isn't used anyway :-P.

I'll submit a fix. I'm also taking care of the trigraph in renderfrontend.cpp.

Comment by Thorsten Fröhlich (thorsten) - Saturday, 12 January 2013, 09:46 GMT
             povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handleroo;
                        ^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handler;
                        ^

No need to worry about these two. The classes use is strictly controlled (a private definition in its parent class definition) has only automatically generated destructors and contains only POD types, so the destructors will always be empty code (and should end up being optimized away). The only way to make this warning go away in this case would be to add empty destructor code in all six classes, which seems excessive. The classes can't get extended or inherited from anywhere else than in this narrow piece of code.

Loading...