[FFmpeg-devel] [PATCH] Fix some typos in avfilter.h

[Stefano Sabatini]

On date Monday 2008-08-25 22:07:30 +0200, Stefano Sabatini encoded:
> On date Sunday 2008-08-24 17:31:12 -0400, The Wanderer encoded:
> > Stefano Sabatini wrote:
> > > On date Sunday 2008-08-24 15:24:21 -0400, The Wanderer encoded:
> > >> Stefano Sabatini wrote:
> > 
> > >>> Yes again, and I now see that my correction was outright wrong,
> > >>> anyway the way the sentence is formulated leads naturally to
> > >>> confusion, as I was reading it as:
> > >>> 
> > >>> And all the references of
> > >>>     a and b,
> > >>>     and a and b
> > >>> will be deallocated.
> > >>> 
> > >>> so it seemed to me just a wrong repetition, so maybe some
> > >>> reforumlation may improve its clearness.
> > >> 
> > >> I can see what you're talking about. It read clearly enough to me,
> > >> but it could certainly be made less potentially ambiguous, though
> > >> I'm having a hard time of coming up with a way to do it without
> > >> using uncommon grammatical forms - something like "Also deallocates
> > >> a, b, and all references thereof.", which is technically correct
> > >> but will seem awkward to many people.
> > > 
> > > What about
> > > "Also all the references of a, b, and a and b themselves will be deallocated."
> > > ?
> > 
> > Because of the nature of a comma-separated list, that expands (or could
> > be interpreted by a reasonable reader as expanding) to
> > 
> > "all the references of a"
> > "all the references of b"
> > "all the references of a and b themselves"
> > 
> > when what we want is
> > 
> > "all the references of a"
> > "all the references of b"
> > "a and b themselves"
> 
> I took it literally, redundant and not very elegant, and elegance is
> for the shoemaker.
>  
> > not to mention that beginning a sentence with "Also" and not having a
> > comma right after it is at least awkward and may be incorrect - and
> > including the comma would result in a too-many-commas problem.
> 
> Too bad for the too-many-commas issue, that means I'm not going to win
> the literature Nobel prize for this patch...
> 
> > > For what regards the second hunk:
> > > "Therefore, we have the format list structure store a pointer..."
> > >             we have the format list structure *to* store a pointer..." 
> > > 
> > > I know both forms are used, can you tell which is the more correct?
> > 
> > Neither is grammatically incorrect, but the nuances of their meanings
> > are slightly different. I personally prefer the current form, although
> > the one in the patch you attached is also acceptable.
> 
> Well, since my change is indifferent to you too then I removed the
> incriminated hunk.
[...]
> Index: libavfilter/avfilter.h
> ===================================================================
> --- libavfilter/avfilter.h	(revision 14964)
> +++ libavfilter/avfilter.h	(working copy)
> @@ -125,7 +125,7 @@
>   * list of the formats supported by each input and output pad. The list
>   * given for each pad need not be distinct - they may be references to the
>   * same list of formats, as is often the case when a filter supports multiple
> - * formats, but will always outut the same format as it is given in input.
> + * formats, but will always output the same format as it is given in input.
>   *
>   * In this way, a list of possible input formats and a list of possible
>   * output formats are associated with each link. When a set of formats is
> @@ -184,8 +184,8 @@
>  
>  /**
>   * Returns a format list which contains the intersection of the formats of
> - * a and b. And all the references of a and b, and a and b will be
> - * deallocated.
> + * a and b. Also, all the references of a, all the references of b, and
> + * a and b themselves will be deallocated.
>   *
>   * If a and b do not share any common formats, neither is modified, and NULL
>   * is returned.

I'll hopefully apply the bloody thing tomorrow if I hear no
objections.

Regards.
-- 
FFmpeg = Foolish & Funny Mega Proud Evil Game