[FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Mark Thompson]

On 08/11/17 22:03, Rostislav Pehlivanov wrote:
> On 8 November 2017 at 21:49, Mark Thompson <sw at jkqxz.net> wrote:
> 
>> On 08/11/17 21:26, Rostislav Pehlivanov wrote:
>>> Signed-off-by: Rostislav Pehlivanov <atomnuker at 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 @};}).
>>>
>>> + at 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