[Clam-devel] New plugins: compilation errors and warnings

David García Garzón dgarcia at iua.upf.edu
Tue Aug 21 08:08:11 PDT 2007

David, the human code janitor, says:

Plugins are nice because they make the development faster but they are also 
out of testfarm compilation, so pay some attention to them until we add them: 
Some of the new plugins are not compiling:

ContinuousExcitationSynthesizer.cxx:5:40: error: CLAM/SinusoidalSynthesis.hxx: 
No such file or directory

OSCSourceProcessing.hxx:26:25: error: OscSource.hxx: No such file or directory
[This one is a case problem. OSCSource.hxx actually exists but OSC not Osc. 
Probably committed from a case unsensitive platform]

I also recommend you to pay attention to the warnings. Some of them are really 
dangerous. Other warnings just generate noise and camouflage the dangerous 
ones. In any case, is a good thing to remove them. Some examples:

ControlStreamSegmentator.cxx: In member function ‘bool 
ControlStreamSegmentator::IsNewVoice(float, float)’:
ControlStreamSegmentator.cxx:43: warning: statement has no effect
ControlStreamSegmentator.cxx:45: warning: control reaches end of non-void 

The second warning is very dangerous. It normally leads to uninitialized 
lvalues. Compiler should signal that as a compilation error. This warning 
happens a lot on Greg's code. Some critical on ConcreteStart/Stop 
implementations that may render the processing unusable or not depending on 
the unitialized memory content.

ContinuousExcitationControlSource.hxx:39: warning: ‘class 
CLAM::ContinuousExcitationControlSource’ has virtual functions but 
non-virtual destructor

This has complications whenever you do a delete over a pointer to the base 
class containing polymorphically the object.

Polynomial.cxx:178: warning: ‘q’ may be used uninitialized in this function

This warning is one of valgrind's preferred. It promises joy and fun by 
debugging errors deriving from this warning. Not Abe's fault, Eissemberg code 
is borrowed, but that code needs an assembler-to-modern-languages 
refactoring. No need to define variables at the beginning we can use local 
scope temporary variables, not need to use goto!, no need to reuse registers, 
no need to name variables by a single meaningless letter. And yes, q may be 
used unitialized. And for example here:
FormantExtractor.cxx:112: warning: ‘f’ may be used uninitialized in this 

The ones like this are dangerous just in very few cases but they add a lot of 
noise and a lot of them can be removed by using the proper type for each 
case, for instance using unsigned for std::vector indices, or signed for 
CLAM::Array indices.


More information about the clam-devel mailing list