Re: VFS code questions

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Fri, Feb 25, 2005 at 01:04:24AM -0800, Kevin M. Kilbride wrote:
> As I'm attempting to thread my way back into the deep hierarchy of 
> preprocessor macros in the UFS headers, I'm finding macros two or more 
> layers deep with variable return types that perform comparisons between 
> signed and unsigned objects and (more disturbingly) use int32 masks on 
> int64 values. The invoking code then coerces the results of these macros 
> to fix their type and explicitly discard high-order bits that may have 
> been left set by mask sign-extension and which (presently) aren't needed 
> anyway.

Some of this needs to be done to avoid overflows in intermediate results.
Some is just historic garbage. Some might be actual fauls.
It's difficult to decide in each case.

> 1. Is there a coding policy issue at Dragonfly that precludes the use of 
> static inline functions, as opposed to preprocessor macros? Is somebody 
> going to shoot me if I attempt to thread my way back through the 
> type-spaghetti of these header files and write them out as inlines? If 
> this is done with the __inline__ keyword, it shouldn't break user code 

Don't use __inline__, that's a GNUism. Use __inline, which is a
preprocessor macro defined in sys/cdefs.h and handles unavailability
of inline support correctly.

> compiled with GCC even if the pedantic ANSI mode is used. It may, 

Pedantic ANSI mode is the most stupid thing GNU ever invented.
At least from an OS writer perspective :) Don't care about it.

> however, force separate instances to be emitted in each compilation unit 
> if optimization is turned off (actually, in GCC 3.4 you can explicitly 

That's more a bug in GCC than a feature. In fact, the handling of
extern inline is a good example of broken GCC design in this case.

> tag functions for inlining even when optimization is turned off, but 
> that's of no use at this point, since GCC 2.95 is the default system 
> compiler). Anyone compiling without optimization is not likely to be 
> concerned about performance penalties incurred from the function call 
> overhead, and it seems a small price to pay for making these logic atoms 
> penetrable to type analysis by both humans and compilers. It's a lot 
> easier to find a fault when the compiler points you to a line of code in 
> your inline definition than it is if it complains about fifty different 
> instances of macros that have been expanded into single lines of source 
> code.

For short code, I normally prefer macros. Inline functions are useful,
if they have a clean semantic and can make use of the type checking.

> 2. Being forced to unravel the underlying type of objects in these 
> macros almost begs a careful reconsideration of existing type 
> relationships. For example, why are so many obviously-non-negative 
> parameters (like masks) in the FFS superblock struct declared as signed 
> integers? Actually, almost everything is signed. Will it break something 
> horribly if these are flipped to unsigned integers of comparable width?

That often has historic reasons. I would be *very* careful about
changing it. The best person to consult is Kirk though.

Joerg