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 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.) - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel