[x264-devel] [PATCH] improve malloc checks to allow graceful exit on malloc failures

Loren Merritt lorenm at u.washington.edu
Mon Jul 27 14:31:56 CEST 2009


On Sun, 26 Jul 2009, Steven Walters wrote:

> oh wow, i never would of thought of something like that....
> before i resubmit a new patch, did you notice any other issues?
> (besides an issue in x264_frame_new i found after emailing it out)

I like my sizeofs they way they are written in most of x264, without extra 
spaces.

> +#define fprintf(out,...) (fprintf(out,__VA_ARGS__), fflush(out)) // POSIX automatically flushes on printing to a stream, but win32 doesn't.

POSIX automatically flushes on printing a newline to a tty.

> +static ALWAYS_INLINE int x264_pthread_create( x264_pthread_t *t, void *a, void *(*f)(void *), void *d )

Not speed critical, so just inline. And even that much is only to avoid 
warnings about unused static functions.

> + *  alloc data for a picture. You must call x264_picture_clean on it.
> + *  returns -1 if malloc failed. */

returns 0 on success, or -1 on malloc failure.

> -static void x264_bitstream_check_buffer( x264_t *h )
> +static int x264_bitstream_check_buffer( x264_t *h )
>  {
> +    uint8_t *bs_bak = h->out.p_bitstream;
>      if( ( h->param.b_cabac && (h->cabac.p_end - h->cabac.p < 2500) )
>       || ( h->out.bs.p_end - h->out.bs.p < 2500 ) )
>      {
> -        uint8_t *bs_bak = h->out.p_bitstream;
>          intptr_t delta;
> -        int i;
> +        int i, length = h->out.i_bitstream;
> +        int length16 = length & ~15;
>
>          h->out.i_bitstream += 100000;
> -        h->out.p_bitstream = x264_realloc( h->out.p_bitstream, h->out.i_bitstream );
> +        CHECKED_MALLOC( h->out.p_bitstream, h->out.i_bitstream );
> +        h->mc.memcpy_aligned( h->out.p_bitstream, bs_bak, length16 );
> +        if( length16 != length )
> +            memcpy( h->out.p_bitstream + length16, bs_bak + length16, length - length16 );

Align the copy amount so that memcpy_aligned can do it alone. It's not 
like an extra 15 bytes out of a margin of 2500 matters.

--Loren Merritt


More information about the x264-devel mailing list