Re: [codec] Format for the codec specification

[Jean-Marc Valin <[e-mail]>]

On 10-09-25 04:55 AM, Riccardo Bernardini wrote:
> A question just came to my mind: what about bugs in the C code? Suppose,
> for example, that the algorithm requires the computation of a DCT of a
> block of samples and that there is some typo in the constants used in
> the C code, so that what the C code computes is not the DCT, but
> something similar and the difference is such that it really does not
> matter in most cases, but causes very bad performances (when compared
> with theoretical description) in others. In this case, the precedence
> would go to the "wrong" description.

Judging from the bugs I have had in CELT over the development, these 
tend to be a lot more subtle than what you describe above, like corner 
cases that likely would not be covered by the text description either. 
In any case, should an error be found in the source code, the best would 
be to simply publish an updated version.

> Another doubt about having a C code as a normative reference: could
> portability issues make the code "ambiguous"? For example, a code could
> use the assumption that int is _exactly_ 32 bits long and short is
> _exactly_ 16 bits. If the same code is run on a processor that uses,
> say, 64 bits for int and 32 for shorts, maybe the results could be
> different. Of course, you can solve this _specific_ issue by including
> stdint.h (not available everywhere, though) and using types like
> int16_t, but what I want to point out is that we must pay attention to
> this type of portability issues, if we want the meaning of the C code
> being non-ambiguous. Another example, much more subtle, could be

That's already how the CELT and SILK source code are written. There are 
typedefs for integers with exactly 16 bits or exactly 32 bits.

> As far as I know (but I am not a C language-lawyer), the standard grants
> that conversion pointer-to-integer-to-pointer will give the original
> pointer back, but nothing is said about the case above (imagine an
> architecture where addresses can be only even). Although the code above
> would work on a typical x86 architecture, I would not use it in a code
> that should play the role of a reference.

Assuming that pointers can be stored in integers is bad and we just have 
to make sure not to have any of that in the reference source code. 
There's no need for it in a codec anyway.

> Although I agree that errors and ambiguities could creep in the
> mathematical description, maybe it is easier to write a correct and
> unambiguous mathematical description rather than a program code (in
> whatever language is written).

Quite the other way around. Writing a correct and unambiguous 
mathematical description for thousands of line of code is nearly 
impossible. Either you write it in plain English and get all the 
ambiguities of natural language, or you write *everything* with 
equations, in which case what you have is the equivalent of pseudo-code. 
Also, a C reference has the advantage that you can verify it simply by 
compiling it.

Cheers,

	Jean-Marc