On 8 November 2017 at 22:20, Mark Thompson <s...@jkqxz.net> wrote:
> On 08/11/17 22:03, Rostislav Pehlivanov wrote:
> > On 8 November 2017 at 21:49, Mark Thompson <s...@jkqxz.net> wrote:
> >
> >> On 08/11/17 21:26, Rostislav Pehlivanov wrote:
> >>> Signed-off-by: Rostislav Pehlivanov <atomnu...@gmail.com>
> >>> ---
> >>> doc/developer.texi | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/doc/developer.texi b/doc/developer.texi
> >>> index a7b4f1d737..de7d887451 100644
> >>> --- a/doc/developer.texi
> >>> +++ b/doc/developer.texi
> >>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x =
> >> @{ .i = 17 @};});
> >>> @item
> >>> compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
> >>>
> >>> +@item
> >>> +for loops with variable definition (@samp{for (int i = 0; i < 8;
> i++)});
> >>> +
> >>> @item
> >>> Implementation defined behavior for signed integers is assumed to
> match
> >> the
> >>> expected behavior for two's complement. Non representable values in
> >> integer
> >>>
> >>
> >> IMO if you want this it would be better to just allow mixed statements
> and
> >> declarations, with this as a consequence.
> >>
> >> Can you comment on what the consequences would be for platform support?
> >> It would remove support for at least one platform I know of (the TI ARM
> >> compiler). I've no idea whether it or any other platform which would be
> >> broken has any users, though.
> >>
> >
> > No, I'm kind of against mixed statements and declarations, as are many
> > people here. It mostly does make the code look worse and encourages
> overuse
> > of variables.
>
> I think the opposite. I find declaration inside the loop header ugly and
> weird, while mixed declarations and code do make sense in some cases: e.g.
> pointer chasing through structures with different types - declaring all the
> variables in advance is just annoying. (Maybe that's not strong enough to
> allow it everywhere if you believe that people will use it inappropriately
> though.)
>
>
I'm pretty sure its because you're not used to them yet. I'm not taking
this as a nak.
If you want mixed declaration submit a patch later on and let people
comment on it.
> > I'm absoultely sure no compiler worth supporting would be broken. If any
> > +15 year old ones do get broken it would be well worth because it would
> > still ease maintaining a lot. I'm also quite sure no compiler that would
> be
> > broken by this would support compiling ffmpeg at all.
> > This is still an essential feature of C99 after all and we don't use C89.
> TI at least disagrees with you, releases are still made without full C99
> support. I know it certainly has use on embedded platforms (though likely
> C6000 more so than ARM), but I don't know if anyone builds libavcodec or
> similar with it. (I don't use it - I only know this because Diego recently
> asked if anyone could test whether it could build libav, and I verified
> that it could after fixing some minor issues. He couldn't find any users,
> though, and the support was removed anyway.)
>
>
If you're not aware of anyone compiling ffmpeg with it then don't even
bother mentioning it.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
