search for: _ogg_calloc

...; + linebuffer=(char*)_ogg_malloc(lbufsize); }else{ lbufsize*=2; - linebuffer=_ogg_realloc(linebuffer,lbufsize); + linebuffer=(char*)_ogg_realloc(linebuffer,lbufsize); } } @@ -179,6 +179,7 @@ codebook *codebook_load(char *filename){ - codebook *b=_ogg_calloc(1,sizeof(codebook)); - static_codebook *c=(static_codebook *)(b->c=_ogg_calloc(1,sizeof(static_codebook))); + codebook *b=(codebook*)_ogg_calloc(1,sizeof(codebook)); + static_codebook *c=(static_codebook*) + (b->c=(const static_codebook*)_ogg_calloc(1,sizeof(static_codebook))); enc...

...only updated to the latest cvs, but the old version also experienced this problem), which compile fine on an x86 box I have, but fails on my powerpc. Here's some of the error messages I get while running 'make' in the vorbis directory: mapping0.o(.text+0x284): undefined reference to `_ogg_calloc' mapping0.o(.text+0x284): relocation truncated to fit: R_PPC_REL24 _ogg_calloc ../lib/.libs/libvorbis.a(mapping0.o)(.text+0x298): more undefined references to `_ogg_calloc' follow ../lib/.libs/libvorbis.a(mapping0.o): In function `mapping0_look': mapping0.o(.text+0x298): relocation trun...

...eturn(OC_BADHEADER); @@ -180,7 +180,8 @@ _tp_readbuffer(opb,tc->vendor, len); tc->vendor[len]='\0'; - _tp_readlsbint(opb,(long *) &tc->comments); + _tp_readlsbint(opb,&tmp); + tc->comments=tmp; if(tc->comments<0)goto parse_err; tc->user_comments=_ogg_calloc(tc->comments,sizeof(*tc->user_comments)); tc->comment_lengths=_ogg_calloc(tc->comments,sizeof(*tc->comment_lengths));

...eturn(OC_BADHEADER); @@ -180,7 +180,8 @@ _tp_readbuffer(opb,tc->vendor, len); tc->vendor[len]='\0'; - _tp_readlsbint(opb,(long *) &tc->comments); + _tp_readlsbint(opb,&tmp); + tc->comments=tmp; if(tc->comments<0)goto parse_err; tc->user_comments=_ogg_calloc(tc->comments,sizeof(*tc->user_comments)); tc->comment_lengths=_ogg_calloc(tc->comments,sizeof(*tc->comment_lengths));

Hi, As far as I see in libvorbis most of the places where _ogg_malloc(), _ogg_realloc and _ogg_calloc() is called the return value is not checked for out of memory condition. Is there any plan to change this? For my use-case the application is not allowed to crash. So if libvorbis can not handle this condition, I guess I would need to preallocate a large enough custom memory heap for all kind of v...

On 01/02/2008, Conrad Parker <conrad@metadecks.org> wrote: > On 31/01/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > > This fixes an off by one bug in the user of snprintf, and returns > > negative if writing the > > header returns negative (otherwise we'd just get a short write, losing > > the error). > > This patch

....com <ogg.k.ogg.k@googlemail.com> wrote: > I've had a second look, and I believe there really was a bug there, > though my patch may not be optimal. > > As an example of an off by one bug: > > On the first run through the code, message_header_fields will be NULL, > so _ogg_calloc will be called. Assume header_key and header_value > are both "X", so strlen of each is 1. message_size will then by 6, and a > block of 6 bytes is callocated. > Then snprintf is called with a byte limit of message_size+1 (7, one more > than the allocated size), with the strin...

...eeking yet; Set up a 'single' (current) logical bitstream + /* seek to the beginning follwing the test */ + if (vf->seekable) callbacks.seek_func(f,0,SEEK_SET); + + /* Set up a 'single' (current) logical bitstream entry for partial open */ vf->links=1; vf->vi=_ogg_calloc(vf->links,sizeof(*vf->vi));

...turn (-133) is caused by the _vorbis_unpack_books code in the lib/info.c in the libvorbis library. In this code in the last poart of the function _vorbis_unpack_books it says ---------------------------------------------------------------- for(i=0;i<ci->modes;i++){ ci->mode_param[i]=_ogg_calloc(1,sizeof(*ci->mode_param[i])); ci->mode_param[i]->blockflag=oggpack_read(opb,1); ci->mode_param[i]->windowtype=oggpack_read(opb,16); ci->mode_param[i]->transformtype=oggpack_read(opb,16); ci->mode_param[i]->mapping=oggpack_read(opb,8); if(ci->mode_...

Hello! First of all a question: When you make the encoder tables (ie: mode_e.h) do you use the mapping0_forward function? Because you made the encoder tables, and after this you did a minor correction in the final beta4 ... (this correction was: additional[0]=fabs(additional[0]*scale); in the mapping0_forward function) (I see this was a bug, and the modification was correct, but this correction

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin