title should likely say _types.h though.
And do you still need cdefs.h, since _types.h already does? style(9) says types.h, but maybe we need to update that too?

This revision is now accepted and ready to land.Apr 23 2025, 8:49 PM

In D49972#1140034, @imp wrote:

title should likely say _types.h though.
And do you still need cdefs.h, since _types.h already does? style(9) says types.h, but maybe we need to update that too?

I could have sworn that style.9 says that one can assume that param.h and (_)types.h include cdefs.h, but I can't find any mention of that.

IMO it's okay to drop the cdefs include, but it doesn't matter much here.

Title will be fixed on commit.

In D49972#1140048, @markj wrote:

In D49972#1140034, @imp wrote:

And do you still need cdefs.h, since _types.h already does? style(9) says types.h, but maybe we need to update that too?

I could have sworn that style.9 says that one can assume that param.h and (_)types.h include cdefs.h, but I can't find any mention of that.

I regularly think similarly, and regularly re-read style.9 to remind me it's indeed not there.

I'm fine with adding such a stance in style.9, as it seems this is already what people automatically assume. That said, I also think we should limit the number of such rules, and stick to explicit includes of directly referenced types/objects, except for technical/historical reasons/shortcomings or long-established practice.

IMO it's okay to drop the cdefs include, but it doesn't matter much here.

This header directly uses features of cdefs.h (such as __printflike), so unless/until we decide on an official stance about cdefs.h being included by _types.h, I'd rather not remove the explicit include.