Well. .h files are a crock to begin with. You can always do stuff like:
*#include "bunch_of_constants_you_will_need.c"* Still.... C is a crock. The preprocessor is a crock. The 'macro' system is a crock. And the language is a crock. (it's from New Jersey, I'm told...) Rather than small proposed changes like this -- what about moving to a more modern language (Rust?). So these types of trivialities are not even conceptualized. </rant> -mac On Mon, Oct 24, 2022 at 1:05 AM Robert Elz <k...@munnari.oz.au> wrote: > Date: Sun, 23 Oct 2022 09:50:20 +0000 > From: Taylor R Campbell <riastr...@netbsd.org> > Message-ID: <20221023095027.eb8ef60...@jupiter.mumble.net> > > | I wasn't able to find a clear statement of the semantics anywhere: > | Is it keyed by (dev,ino), by pathname, by some kind of normalized > | pathname, by file content? gcc's own documentation is very sparse and > | just describes it as nonportable. > > I had not weighed in on this before, but that issue was the biggest > problem I could see with this. > > That and that using guards allows having mutually exclusive (but > different) include files ... though of course they could always be > used for any such cases even if the #pragma scheme became the normal > way. > > | So on balance, #pragma once doesn't seem worthwhile to me today, and > | I think we should stick to traditional include guards for now. > > I agree. > > kre > > >
