Re: CVS commit: src/sys/arch/powerpc/oea

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
> >>> Every header file should include the things it requires to compile.
> 
> 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.  (Well, unless it's an
> internal file, one that shouldn't be included directly.)

assert.h is the *only* header that is not supposed to be idempotent.
Pretty much anything else should be classified as bug.

Another item is that too many of our headers depend on non-standard
compliant types polluting the namespace. Nothing installed in
/usr/include should depend on u_char for example.

> I've got numerous fixes to 4.0.1 for such issues, in case anyone thinks
> it's worth applying this stance to 4.x.

Doing it properly has a chance of creating some fallout and that's not
really acceptable for a release branch, especially one that doesn't get
many non-critical changes.

> > [...] just forward declarations of the structs.
> 
> > (this is, btw, one of the reasons to avoid silly typedefs)
> 
> I'm not sure what typedefs have to do with it.  typedeffing a name to
> an incomplete ("forward") struct type works just fine:
> 
> struct foo;
> typedef struct foo FOO;
> 
> (You can't do anything with a FOO without completing the struct type,
> but you can work with pointers to them....)

Problem is that this requires a guard for the typedef if FOO is supposed
to be defined by multiple files.

Joerg