[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/powerpc/oea
>> I've long felt this way: that, except for a very few examples like
>> <assert.h> that are defined to depend on context, the order of
>> #includes should not matter. In particular, if multiple files must
>> be included, any of them may come first - so any file that generates
>> errors if it's included first needs fixing.
> assert.h is the *only* header that is not supposed to be idempotent.
> Pretty much anything else should be classified as bug.
I'm not talking about idempotency. Idempotency is the question of
is operationally equivalent to
But what I'm talking about is whether
are operationally equivalent.
> Another item is that too many of our headers depend on non-standard
> compliant types polluting the namespace.
This is another issue I have with our include files, but it's
significantly more work to fix, so I've been working around it rather
than fixing it right. (It's also not entirely clear what the right fix
is when more than two levels of software supplier are involved.)
> Nothing installed in /usr/include should depend on u_char for
Well...ideally. But there's a big difference between (say) <stdio.h>
depending on u_char and <dev/qbus/funkyboard.h> depending on u_char.
(I'm not happy about either, but substantially less happy about the
>> struct foo;
>> typedef struct foo FOO;
> Problem is that this requires a guard for the typedef if FOO is
> supposed to be defined by multiple files.
Most of the cases I've seen for this push the incomplete struct
declaration and the typedef into a separate file, wrap it with an
idempotency guard, and then include that from files that need the
struct and/or type. I've seen a very few cases where this hasn't been
done and I think none at all where it couldn't be done if the relevant
software authors cared to bother.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |