tech-kern archive

[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
whether

#include <foo.h>
#include <foo.h>

is operationally equivalent to

#include <foo.h>

But what I'm talking about is whether

#include <foo.h>
#include <bar.h>

and

#include <bar.h>
#include <foo.h>

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
> example.

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
former.)

>> 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.

True.

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


Home | Main Index | Thread Index | Old Index