On Sun, Dec 16, 2018 at 09:42:49PM +0100, Tomas Härdin wrote:
> fre 2018-12-14 klockan 13:44 -0800 skrev chcunningham:
> > avio_read may return EOF, leaving the mimetype array unitialized.
> > fail
> > early when this occurs to avoid using the array in an unitialized
> > state.
> > ---
> >
fre 2018-12-14 klockan 13:44 -0800 skrev chcunningham:
> avio_read may return EOF, leaving the mimetype array unitialized.
> fail
> early when this occurs to avoid using the array in an unitialized
> state.
> ---
> libavformat/id3v2.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> -char mimetype[64];
> +char mimetype[64] = {0};
>
> would be enough
>
Agree! Next patch.
I'd love to do similar for the isv34 branch, but I'm not sure how to detect
> the condition given the EOF behavior for avio_get_str:
> * @return number of bytes read (is always <= maxlen).
> * If
tor 2018-12-13 klockan 11:28 -0800 skrev chcunningham:
> avio_read may return EOF, leaving the mimetype array unitialized. fail
> early when this occurs to avoid using the array in an unitialized state.
> ---
> libavformat/id3v2.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>
>
> Yet another problem that could have been caught by static analysis..
> Wouldn't it be better to always leave the array in a valid state?
>
Will add that in the next patch. It has the extra benefit of protecting the
isv34 branch.
Goto fail; skips a lot of lines that aren't needed if mimetype
ons 2018-12-12 klockan 18:59 -0800 skrev chcunningham:
> avio_read may return EOF, leaving the mimetype array unitialized. fail
> early when this occurs to avoid using the array in an unitialized state.
> ---
> libavformat/id3v2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
