Remove declaration-after-statement C warning

Bart Massey bart at cs.pdx.edu
Wed Sep 11 23:49:06 PDT 2013


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!

(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
>>


More information about the xorg-devel mailing list