[FFmpeg-devel] [PATCH] deals with code that has no effect when executed

Michael Niedermayer michaelni
Thu May 29 23:31:36 CEST 2008


On Thu, May 29, 2008 at 12:56:52PM -0700, Erik Hovland wrote:
> On Thu, May 29, 2008 at 09:14:10PM +0200, Michael Niedermayer wrote:
> > On Thu, May 29, 2008 at 12:02:15PM -0700, Erik Hovland wrote:
> > > On Thu, May 29, 2008 at 08:20:27PM +0200, Reimar D?ffinger wrote:
> > > > On Thu, May 29, 2008 at 10:57:22AM -0700, Erik Hovland wrote:
> > > > > All of the memset calls rely on the compiler to sizeof the array. If
> > > > > a compiler does this then it is outside of the C standard.
> > > > 
> > > > I'd really like a citation of the C standard for that claim...
> > > 
> > > I guess I should do a better job of qualifying that statement. The C
> > > standard does not allow for the sizeof operator to work on dynamic or
> > > externally define types.
> > > http://en.wikipedia.org/wiki/Sizeof
> > 
> > sigh ...
> > wikipedia is NOT the C standard (and thats a good thing). I wouldnt trust
> > any publically editable source blindly.
> 
> Sorry. I was not trusting it blindly. I read it for accuracy. And it was
> accurate for what it says. But unfortunately for me. I was
> wrong about how I was applying it. I have reworked the patch to leave
> out the changes to memset because in each one it is using sizeof
> correctly on static arrays and not.
> 
> Where the standard is ambiguous is stating whether multi-dimensional
> arrays are evaluated. If one were literal about the standard, it could
> be that they are not since they are not specifically qualified. I will
> attempt to figure out what the compiler does as homework before
> submitting a patch  related to this again.
> 
> And I have attached my patch making the suggestions you made.
> 
> > Even less so when the public is mostly people who know java & vb and the
> > information i search for is C ...
> 
> Wow, insulting wikipedia authors as well as java and vb programmers in one
> sentence. Hat trick!
> 
> E
> 
> -- 
> Erik Hovland
> mail: erik at hovland.org
> web: http://hovland.org/
> PGP/GPG public key available on request

> Corrects any code that literally has no effect on execution.
> 
> ffserver.c checks to see if the reference value of feed_filename is
> valid. But feed_filename is a static array in the stream struct. So it
> will always be valid. The patch changes it to a string length check
> instead.
> 
> In udp.c, the call to udp_set_url can return a negative value. But
> dest_addr_len is unsigned. So checking for < 0 of dest_addr_len will
> not check if udp_set_url worked. The patch introduces a signed type
> and checks that instead.
> 
> From: Erik Hovland <erik at hovland.org>
> 
> ---
> 
>  ffserver.c        |    2 +-
>  libavformat/udp.c |    7 ++++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/ffserver.c b/ffserver.c
> index 705c557..613537a 100644
> --- a/ffserver.c
> +++ b/ffserver.c

iam not maintainer of ffserver ...

[...]

> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index effe699..90c134b 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -290,15 +290,16 @@ int udp_set_remote_url(URLContext *h, const char *uri)
>  {
>      UDPContext *s = h->priv_data;
>      char hostname[256];
> -    int port;
> +    int port, addr_len;
>  
>      url_split(NULL, 0, NULL, 0, hostname, sizeof(hostname), &port, NULL, 0, uri);
>  
>      /* set the destination address */
> -    s->dest_addr_len = udp_set_url(&s->dest_addr, hostname, port);
> -    if (s->dest_addr_len < 0) {
> +    addr_len = udp_set_url(&s->dest_addr, hostname, port);

dest_addr_len is int so this should not be needed
I assume you where looking at an old version of ffmpeg?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080529/2af99b8a/attachment.pgp>



More information about the ffmpeg-devel mailing list