On 9/11/13, Bart Massey <b...@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 <pkesh...@gmail.com> > wrote: >> On 9/11/13, Bart Massey <b...@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.coopersm...@oracle.com> wrote: >>>> On 09/11/13 08:52 PM, Daniel Stone wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 11 September 2013 17:31, Mark Kettenis <mark.kette...@xs4all.nl> >>>>> wrote: >>>>>>> >>>>>>> From: Alan Coopersmith <alan.coopersm...@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.coopersm...@oracle.com >>>> Oracle Solaris Engineering - http://blogs.oracle.com/alanc >>>> _______________________________________________ >>>> xorg-devel@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@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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel