Re: [PATCH] style(5): No struct typedefs

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I'm tempted to say that an opaque struct declaration in a .c file
> ought be treated suspiciously -

Depending on what you mean by "an opaque struct declaration", I may
agree or disagree.

If you mean the "struct foo;" without a body, then I think I agree.

But the "struct foo { ... };" that completes the incomplete type
corresponding to the include file's "struct foo;", that I think is the
whole point of opaque structs: the completion is available only under
the implementation hood.  While that may be in a foo-impl.h file, if
only a single file needs it I see no harm in the completion being in
the .c (and indeed I've done it that way often enough).

> (and it would be kind of nice if C had a way to say "all functions
> defined beyond this point are static").

Personally, I'd prefer "all functions defined before this point are
static", since I prefer calls to move textually backward (or, to put it
another way, I prefer to avoid forward declarations when possible).

But I doubt either of those will appear anytime soon.

> And to return briefly, to the issue way up the top of simplifying the
> leader files, there is one change I've wanted to make for ages, but
> just haven't been brave enough to do,

> That is to rip the definition of __NetBSD_Version__ [...] into a new
> header file all of its own [...] with the rule that *no* other header
> file is oermitted to include it.

I'm...not sure I agree with that.

I once built a kernel facility which I wanted to be completely drop-in
to multiple kernel versions (as widely disparate as 1.4T and 5.2).  The
design I came up with was (names probably changed; I'm not digging up
the code to see what names I actually used) a "version.h" file which
looked like

#include <whatever.h> // to get __NetBSD_Version__

#if __NetBSD_Version__ == whatever value 1.4T had
#include <thing/something.h> // where 1.4T keeps it
#define THINGY() do { ...1.4T code for THINGY() ... } while (0)
typedef int COMMON_TYPE; // just an int on 1.4T
#endif

#if __NetBSD_Version__ == whatever value 5.2 had
#include <some/where/else/thing-part1.h> // on 5.2 we need two
#include <yet/another/place/thing-part2.h> // include files
#define THINGY() thingy() // 5.2 has THINGY() nicely encapsulated
typedef struct something COMMON_TYPE; // 5.2 uses a struct
#endif

etc.  It sounds as though you would prefer the #include that pulls in
__NetBSD_Version__ be in every C file that wants to include
"version.h".  This seems counterintuitive, even counterproductive, to
me (and see also below, about #include order).  Or perhaps you'd prefer
that I'd designed those interfaces some other way, rather than with a
version-switch include file?

My own pet include-file peeve is rather different: I strongly believe
that, with very few exceptions (<assert.h> is the only one that comes
to mind), you should be able to re-order your #include lines
arbitrarily without producing any semantic change, and that, if this is
not so, at least one of the include files involved is broken.  I've
been making small steps towards fixing this in my own trees, but it's
still a major mess.

/~\ 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