On Tue, 28 Jan 2020 at 20:43, Petr Viktorin email@example.com wrote:
On 2020-01-27 21:42, Skip Montanaro wrote:
I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's not clear to me that the latter should be #include'd directly from anywhere other than Include/frameobject.h. If that's the case, does the extern "C" stuff still need to be replicated in the lower level file? Won't the scope of the extern "C" block in Include/frameobject.h be active at the lower level?
Whatever the correct answer is, I suspect the same constraints should apply to all Include/cpython/*.h files.
- The #ifndef/#error make a clear point that a include/cpython/*.h file
is only to be included as part of its include/*.h
- The inner extern "C" block overrides the outer one. If they're the
same, it's useless.
I hadn't thought about this before (and presumably Victor hadn't either when he did the initial set of header splits), but yeah, I think you're right - the inner C-style linking declarations are redundant, given the macro definitions checks that ensure these files are always going to be included inside the outer C-style linking declarations.
But I'd call it a minor issue – a style issue, even. Probably not worth worrying about.
A quick code search says there are only 18 header files affected by this at the moment - if we were to clean those up, then any future file splits would presumably copy that improved style, rather than perpetuating the redundancy. So call it a +0 from me for tidying them up.