Lee Revell rlrevell at joe-job.com
Thu Sep 2 18:08:47 PDT 2004

On Thu, 2004-09-02 at 21:02, Jesse Barnes wrote:
> On Thursday, September 2, 2004 5:48 pm, Adam Jackson wrote:
> > On Thursday 02 September 2004 20:28, Lee Revell wrote:
> > > I get tons of warnings compiling xorg.  Is anyone making a concerted
> > > effort to clean up the code?  Are there any coding standards I could
> > > refer to for the recommended way to clean these up?  I would be willing
> > > to help but I don't want to duplicate any efforts.
> >
> > Sounds like you're volunteering ;).  No one is undertaking such a project
> > that I know of, though I'm vaguely planning to convert all the K&R-style
> > code to ANSI sometime after 6.8 ships.  This would at least take care of
> > the "function declaration is not a prototype" warnings.
> Sounds like good stuff for the Xjanitor project too.

Eh, I don't have a ton of time to contribute, but some of them look like
they wouldn't be too hard to fix.

The most common seems to be 'string length of FOO is greater than ISO C
compilers are required to support'.  Is this warning something people
even care about?  If the xorg project has decided that they want really
long strings at the expense of ISO conformance then maybe there's a flag
to silence this one.

> > As usual, the best way to do this would be to open a bug for it, attach the
> > patch, and await feedback.  Best to do it in stages too, for example all of
> > one class of warning for just the video drivers in one patch, to make it
> > easier to review.
> It's better to file a bug then post a patch to the list?  Won't more people 
> see the patch if it goes to the list?  Ideally, a head janitor with checkin 
> access could checkin such a patch after it had been approved by the list.  At 
> least, that seems to work pretty well for lkml, but I'm biased.

Bug reports are good for non-coders, or if you have a serious bug that
you want a documented resolution process for, but I always thought if
you can post a patch then filing a bug report is a waste of time.


More information about the xorg mailing list