Re: [dev] [sbase] style

From: <random832_AT_fastmail.us>
Date: Wed, 19 Nov 2014 15:15:06 -0500

On Wed, Nov 19, 2014, at 13:51, k0ga_AT_shike2.com wrote:
>
> > system headers should come first, then a newline, then libc headers
> > then a newline then local headers.
>
>
> I usually do just the inverse, first libc headers and later system
> headers.
>
> > the libc headers are guaranteed to work regardless of the order of
> > inclusion but need to come after the system headers. From what I
>
> Are you sure about that?. I know that C90 guarantees that any
> standard header will not include any other standard header (althought
> it is sad that a lot of compilers ignore this rule), but I have never
> read anything about dependences between standard and system headers.

C90, or any version of standard C, does not have a concept of "system
headers", other than giving implementations permission to place their
own implementation-defined files in places searched by #include
<h-char-sequence>.

POSIX does not, as far as I can tell, allow systems to require headers
to be included in any certain order.

I have no idea what the categories "system headers" and "libc headers"
refer to in the post you are replying to, what operating system he is
using (certainly not POSIX - I think when I saw the post I got the vague
impression he was talking about Plan 9), or which category the standard
C headers or POSIX headers might fall into. There are such
order-dependencies on some non-POSIX unix systems (I once had to move
sys/types.h above socket.h to get a program to compile on 2.11BSD), and
it may or may not make sense to order headers in line with those as a
matter of tradition.

In general, both standards require all headers to declare, for example,
any typedefs that are present in the signature, without implying the
inclusion of any other header that also defines the same types, and
leaving it up to the implementation to determine how to accomplish this.
For example, unistd.h cannot require that sys/types.h be included first
just because it uses off_t which is also found in sys/types.h; the
author of the header files has to figure out how to make them both
define off_t without any conflict if both are included.

I couldn't find the guarantee you mentioned, that one header shall not
include another header, and I can't think of how doing so would affect
the behavior of any strictly conforming program.
Received on Wed Nov 19 2014 - 21:15:06 CET