On 18/10/13 09:07, Martin Storsjö wrote:
> Contrary to common intuition, a 32 bit integer left shifted
> by a 64 bit integer does not promote the 32 bit integer to
> 64 bit before shifting.
> 
> Based on a patch by Carl-Eugen Hoyos.
> 
> This reverts commits 979e9e8f3671d49463fd309dcd3d9c445a4c63de
> and 86f042dcabde2a5386dbd95ab0451b274987d253 and adds a few other
> casts that were missing originally.
> ---
>  libavformat/wtv.c |   16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/libavformat/wtv.c b/libavformat/wtv.c
> index 5099739..97b73f3 100644
> --- a/libavformat/wtv.c
> +++ b/libavformat/wtv.c
> @@ -48,7 +48,7 @@
>   *
>   */
>  
> -#define WTV_SECTOR_BITS    INT64_C(12)
> +#define WTV_SECTOR_BITS    12
>  #define WTV_SECTOR_SIZE    (1 << WTV_SECTOR_BITS)
>  #define WTV_BIGSECTOR_BITS 18
>  
> @@ -94,7 +94,7 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf, 
> int buf_size)
>              int i = wf->position >> wf->sector_bits;
>              if (i >= wf->nb_sectors ||
>                  (wf->sectors[i] != wf->sectors[i - 1] + (1 << 
> (wf->sector_bits - WTV_SECTOR_BITS)) &&
> -                avio_seek(pb, wf->sectors[i] << WTV_SECTOR_BITS, SEEK_SET) < 
> 0)) {
> +                avio_seek(pb, (int64_t)wf->sectors[i] << WTV_SECTOR_BITS, 
> SEEK_SET) < 0)) {
>                  wf->error = 1;
>                  break;
>              }
> @@ -119,7 +119,7 @@ static int64_t wtvfile_seek(void *opaque, int64_t offset, 
> int whence)
>          offset = wf->length;
>  
>      wf->error = offset < 0 || offset >= wf->length ||
> -                avio_seek(pb, (wf->sectors[offset >> wf->sector_bits] << 
> WTV_SECTOR_BITS)
> +                avio_seek(pb, ((int64_t)wf->sectors[offset >> 
> wf->sector_bits] << WTV_SECTOR_BITS)
>                                + (offset & ((1 << wf->sector_bits) - 1)), 
> SEEK_SET) < 0;

Might be good having a function to seek by sector directly so we would
avoid the problem in the future.

Maybe seek_by_sector(pb, sector, offset) would do.

lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to