indent(1): Capsicumify

[cem]

Summary

This is a nice and trivial program for sandboxing. One input file, one
output file.

Test Plan

truss indent indent.c indent-formatted.c

[pfg]

Looks good to me ... Thanks!

[emaste]

head/usr.bin/indent/indent.c

53

as @jhb pointed out in IRC, style(9) calls for sys/param.h or sys/types.h to be first

[cem]

head/usr.bin/indent/indent.c

53

This is actually completely unspecified in style(9), but matches convention.

Convention also calls for capsicum.h not to include other headers, but it does anyway. (Which is why this even compiles without param.h first.)

[imp]

head/usr.bin/indent/indent.c

53

If it is in the examples in style(9), it's part of the convention, since that's best read as an annotated example with parenthetical comments and asides.

In this case it's by weak association:

#include <sys/cdefs.h>

Kernel include files (i.e. sys/*.h) come first; normally, include
<sys/types.h> OR <sys/param.h>, but not both. <sys/types.h> includes
<sys/cdefs.h>, and it is okay to depend on that.

#include <sys/types.h>
etc

So the example has it first (after cdefs for FreeBSD ID) and only one of types.h and param.h is included.

This is a tricky part of style(9), but has come up many times in the past and is the settled conventions as evidence by a substantial number of files that do this.

It also doesn't actually state not to include dependencies. That's just part of the tribal knowledge of best practices of the project. capsicum.h aims to be an more than FreeBSD standard, which has an externally defined interface which allows for more namespace pollution than is usually strived for (which is the real reason so many files avoid including other files: strict POSIX compliance basically demands it in many cases).

[emaste]

So the example has it first (after cdefs for FreeBSD ID) and only one of types.h and param.h is included.

Unfortunately it is not really clear in style(9) that these separate sections actually form a single example, and there's only one sys/ header file so no example that shows types.h/param.h should come first. Nobody's suggesting this aspect of our style is wrong, just that it's not documented.

[imp]

In D7920#164700, @emaste wrote:

So the example has it first (after cdefs for FreeBSD ID) and only one of types.h and param.h is included.

Unfortunately it is not really clear in style(9) that these separate sections actually form a single example, and there's only one sys/ header file so no example that shows types.h/param.h should come first. Nobody's suggesting this aspect of our style is wrong, just that it's not documented.

Understood. Last time I modified style(9) it was 1000x the effort that the reward gave me. This is not the only example of things documented only by example in style(9) and fixing them all would be even worse. It's the common interpretation of style(9) and has been for two decades. Cleaning up all of style(9) to codify this tribal knowledge would take much effort and not be worth it. Last time I tried it was horrible.

[emaste]

I don't mean to discount any of that, just that this is not documented even by example. It appears the rule is: only one of sys/param.h or sys/types.h should be included, and should be included after the sys/cdefs.h used for __FBSDID and before any other sys/*.h includes. But no other sys/*.h headers appear in the example, so there's nothing that demonstrates sys/types.h or sys/param.h should come before other sys/*.h.

sys/ktrace.h and sys/queue.h do appear in style(9), but they are clearly not part of the same example.