<net/sff8472.h>: Conditionally export table of ID names

[jhb]

Summary

Only export the array of ID names if either _WANT_SFF_8024_ID or
_WANT_SFF_8472_ID is defined. Exporting them unconditionally can
trigger unused variable warnings if a consumer doesn't use the array.

[jhb]

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

[olce]

In D49955#1139102, @jhb wrote:

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

Yes. That's why this approach seems somewhat impractical, and also ad-hoc as we would have to do that anytime we add some static constant to some header. This is a rare case, and right now I'm not really sure why we would need to do that. Perhaps to simplify cases where the same header is used in the kernel and in userland?

From D49830, I gather you also tried to disable -Wunused-variable. Isn't that approach enough? It has the benefit to be more generic. That said, the macro guard is anyway needed if the header is included by userspace and the constant not used.

[brooks]

There's an argument there should be a DECLARE_SFF_8024_ID macro that consumers add to their .c file, but is easy and has precedent.

IMO it's a bug to add static definitions to headers to they should warn when not appropriately guarded.

[olce]

In D49955#1141599, @brooks wrote:

IMO it's a bug to add static definitions to headers to they should warn when not appropriately guarded.

I think you're right (if these occurrences exist for the reason I guessed above).

[jhb]

In D49955#1141577, @olce wrote:

In D49955#1139102, @jhb wrote:

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

Yes. That's why this approach seems somewhat impractical, and also ad-hoc as we would have to do that anytime we add some static constant to some header. This is a rare case, and right now I'm not really sure why we would need to do that. Perhaps to simplify cases where the same header is used in the kernel and in userland?

From D49830, I gather you also tried to disable -Wunused-variable. Isn't that approach enough? It has the benefit to be more generic. That said, the macro guard is anyway needed if the header is included by userspace and the constant not used.

I just don't like promulgating more special cases in the test-includes Makefile. Also, the static variables are kind of gross as they end up in .rodata of all compiled binaries even when not used.