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

[David García Garzón]

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:
ContinuousExcitationSynthesizer.cxx:5:40: error: CLAM/SinusoidalSynthesis.hxx: 
No such file or directory

oscSource:
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 
function

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 
function


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.


David.