That can be avoided by using a suitable formula for DNAME_INLINE_MIN
>
> > #define d_... has a similar problem => the potential to break previously
> > compiling source code.
>
> Again, not really. The #define d_... scheme would leave all of the fields
> in their original locations, just giving them new names within the named
> struct, and the defines would be the backwards compatible (and probably
> still preferrable) way to access these fields. I don't _think_ it would
> cause any compiler struct alignment issues to just put the same fields
> in another struct, but I could be wrong.
It won't help if any code is doing
void function()
{
int d_name;
...
}
Preprocessor doesn't care about scopes so it would turn that into
an syntax error.
Anyways it is moot as Manfred's latest solution looks like the way to go.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/