[CELT-dev] Possible Bug

Riccardo Micci riccardo.micci at cambridgeconsultants.com
Thu Sep 2 06:00:38 PDT 2010

Decoding the second frame the function unquant_fine_energy is executed. 
Within it ec_dec_bits subfunction is executed (q2 = ec_dec_bits(dec, 
fine_quant[i]);). Ec_dec_bits calls ec_decode_raw 
In ec_decode_raw within the while loop the following line is executed:
value |= _this->end_byte>>(8-_this->end_bits_left)<<count;
As you can see end_byte is read and used before nothing else has written 
in it before. 
This produce different results on different platforms.


Riccardo Micci
Senior DSP Engineer, Wireless Group 
Cambridge Consultants
Science Park, Milton Road 
Cambridge, CB4 0DW, England
Switchboard: +44 (0)1223 420024
Direct dial: +44 (0)1223 392402
Mobile: +44 (0)
Fax: +44 (0)1223 423373
riccardo.micci at cambridgeconsultants.com

Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca> 
02/09/2010 13:41

celt-dev at xiph.org
riccardo.micci at cambridgeconsultants.com
Re: [CELT-dev] Possible Bug

> The problem comes decoding the next frame. Since now "shortBlocks" is 
> "end_byte" is not initialized anymore and next functions read it before
> update.
> Can someone confirm this behaviour? In my case i modified ec_dec_init
> function to initialize it as well. What is the correct value?

Can you give a bit more information on what's happening? The end_byte 
field does not need to be initialized because it should get read when 
end_bits_left is zero. In what function is the uninitialized read 
happening and what happens then?


This email is from Cambridge Consultants Limited, Science Park, Milton 
Road, Cambridge CB4 0DW with registered number 1036298 England. It may 
contain confidential information. It is intended for the addressee only 
and may not be copied or disclosed to any third party without our 
permission. If you are not the intended recipient please contact the 
sender as soon as possible and delete the material from any computer. If 
this email has been sent as a personal message to the addressee, the 
sender is not acting in his/her capacity as an employee or officer of 
Cambridge Consultants Limited and no liability is accepted for the content 
of any such email. Outgoing email may be monitored for the purpose of 
ensuring compliance with our email policy and relevant laws.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20100902/8df354e1/attachment-0002.htm 

More information about the celt-dev mailing list