Date: Thu, 16 Mar 2023 05:21:47 +1100
From: matthew green <m...@eterna.com.au>
Message-ID: <6173.1678904...@splode.eterna.com.au>
| doing this should never be more than a quick hack
| and not in the commited treed.
It probably also needs to exclude machine generated code, eg:
yacc produces an "extern" declaration in y.tab.c - but that's
not going to have any of the issues for which this is sought
to be prohibited.
Similarly, in /bin/sh there is a generated .c file which has
pieces copied from other files, with all the vars extracted
made into extern - that also has none of the issues, the
types are guaranteed to be the same by the way the file is
generated.
I can also see some potential issues where one program borrows
a file from another (particularly if the other is something
imported from an external source) and needs to access vars or
funcs defined in that file from one of its own files - where
in the original program they're local (in the imported version
it might even need to compile with -Dstatic= to make things
visible). Sure - we can require that the importing program
generate a separate .h file for the extern declarations, even
if that .h file is only even included (by anything) once - but
that seems kind of a meaningless restriction - the compiler
still doesn't get to check the declarations, as the imported file
isn't using that .h file.
But as long as we remember this is just style - guidelines, not
necessarily applicable absolutely everywhere, when there is good
reason not to apply them, then that's fine - for most uses I agree
with the objective.
kre
