Remove declaration-after-statement C warning

[patrick keshishian]

On 9/11/13, Bart Massey <bart at cs.pdx.edu> wrote:
> I'm talking about a programming convention that is supported by the
> existing C language, has no associated cost, complexity or difficulty,
> does not make significant semantic or syntactic change to programs, is
> easy to learn, and yet helps to prevent a common kind of bug. So I'll
> assume your comparison is intended as a troll. Good one!

My bad for chiming in. I can see your logic remains infallible.

Cheers,
--patrick


> (For the record, though: yeah, I prefer to program in languages such
> as Nickle and Haskell that largely eschew pointers and their
> associated bugs. You should try it sometime: it's pretty nice.)
>
> --Bart
>
> On Wed, Sep 11, 2013 at 11:30 PM, patrick keshishian <pkeshish at gmail.com>
> wrote:
>> On 9/11/13, Bart Massey <bart at cs.pdx.edu> wrote:
>>> Well now I feel bad; I thought we had discussed this before and
>>> everyone was OK with it. I should revert that patch now, I guess? My
>>> sincere apologies for being premature.
>>>
>>> For the record, though, I totally and vehemently disagree with the
>>> "bad style" argument. Separating definition from declaration is bad
>>> style, because it makes it easier to use a variable before it has been
>>> initialized. Whenever possible, variables should be declared at point
>>> of first assignment, so that it is clear that they have been
>>> initialized.(If you disagree, I challenge you to go back through old
>>> code and see how many uninitialized-variable bugs would have been
>>> easily caught by this convention--it will be lots.)
>>
>> That's a really poor argument. Using that logic: Do you know how
>> many off-by-one, buffer-overflow, double-free, etc. bugs could be
>> prevented if use of pointers are removed?
>>
>> bah...
>> --patrick
>>
>>> Further, said
>>> definition should be as close as possible to the position of first
>>> use. This allows one to easily see the definition when trying to
>>> understand the code that uses the variable: a big aid to debugging and
>>> analysis.
>>>
>>> I know of no plausible SE case for declaring variables way up at the
>>> top of the block they are defined in other than tradition. It was
>>> originally done that way to make it easier for Fortran compilers,
>>> AFAIK. It's error-prone and makes code harder to read: it's a
>>> tradition we should enthusiastically abandon.
>>>
>>> --Bart
>>>
>>> On Wed, Sep 11, 2013 at 8:57 PM, Alan Coopersmith
>>> <alan.coopersmith at oracle.com> wrote:
>>>> On 09/11/13 08:52 PM, Daniel Stone wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 11 September 2013 17:31, Mark Kettenis <mark.kettenis at xs4all.nl>
>>>>> wrote:
>>>>>>>
>>>>>>> From: Alan Coopersmith <alan.coopersmith at oracle.com>
>>>>>>> Pushing the patch is easy - determining if it's our consensus to
>>>>>>> change
>>>>>>> the X.Org coding style to allow this is the hard part.
>>>>>>>
>>>>>>> Does anyone object to allowing this change to the coding style now
>>>>>>> that
>>>>>>> it's no longer a hard requirement for OpenBSD's ports?
>>>>>>
>>>>>>
>>>>>> It's still bad style.
>>>>>
>>>>>
>>>>> Yeah, I actually totally agree.
>>>>
>>>>
>>>> The one bit I would like to have is declarations in for/while loops,
>>>> such
>>>> as
>>>>         for (int i = 0; i < MAXSCREENS; i++)
>>>>
>>>> Having declarations in the middle of code blocks I can live without,
>>>> though
>>>> in a few cases it would reduce the complexity of our #ifdef nesting.
>>>>
>>>>
>>>> --
>>>>         -Alan Coopersmith-              alan.coopersmith at oracle.com
>>>>          Oracle Solaris Engineering - http://blogs.oracle.com/alanc
>>>> _______________________________________________
>>>> xorg-devel at lists.x.org: X.Org development
>>>> Archives: http://lists.x.org/archives/xorg-devel
>>>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>> _______________________________________________
>>> xorg-devel at lists.x.org: X.Org development
>>> Archives: http://lists.x.org/archives/xorg-devel
>>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>>
>