xserver janitorial work

[Greg KH]

On Wed, Jun 07, 2006 at 05:22:28PM -0700, Keith Packard wrote:
> On Wed, 2006-06-07 at 16:15 -0700, Greg KH wrote:
> 
> > > - parameters that get promoted to int or double in K&R style
> > > (they should ihmo be declared as int or double in "ansi" declaration, in 
> > > order to be compatible with old code)
> > 
> > How would this happen?  With variables that have no explicit "type"?
> 
> You clearly aren't used to the nightmare known as K&R C.
> 
> foo (float x) vs foo (x) float x;
> 
> In the ANSI case, the type of 'x' is float, and in the K&R case, the
> type of 'x' is passed as a double and then converted to a float as it is
> used. That was trivial on the PDP11 and VAX where float and double had
> the same data in the first 32-bits (exponents were the same length).

Ah, no, I admit that my K&R C days were all with embedded processors
with no floating point at all, so I was not aware of this issue.  Thanks
for pointing it out, I'll watch out for it.

> > The compiler _should_ catch this now with a proper function prototype
> > (I'm also trying to clean up these and the ever popular "just stick an
> > extern foo(int); in this other file" issues so this is caught at build
> > time.)
> 
> It's only a warning these days, and with the number of warnings emitted
> by the compiler when faced with X code, they're generally lost in the
> noise. Yes, the goal is to get to zero warnings, but as an intermediate
> step, we must be careful to not break things even while most of us
> continue to ignore huge piles of warnings coming out of the compiler
> from the legacy code. This is why there hasn't been a wholesale
> conversion of function declarations and instead we've done it a bit at a
> time, to not get careless.

Well, as I'm watching the warnings very carefully right now (and there
really aren't that many of them, they are just hard to see in the build
process right now (I'll work on that later...)), I'll watch out for
these.  It's also my goal to get rid of most of these warnings.

> > But yes, I understand the issues and will be very careful to try to not
> > mess up.
> 
> That's all we ask; it's a huge, fragile code base that all runs as root
> with most of the delicate parts of your system mmaped in. Treat it like
> kernel code that hasn't been well maintained, and you'll get a good idea
> of our caution.

Will do, I am very familiar with "kernel code that hasn't been
maintained" :)

> > I guess I'm just used to "cleaner" .c code, and IMHO, no #ifdefs in the
> > middle of a function is a good idea.
> 
> It's an interesting position, but I'm not sure it's more or less clear
> in all cases.

Ok, I'll hold off from doing anything like this for now, it looks like I
have enough other "low lying fruit" to go after for a while.

thanks,

greg k-h