On Fri, Nov 15, 2013 at 2:39 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 11/15/2013 08:31 AM, Joseph S. Myers wrote: >> >> On Fri, 15 Nov 2013, Richard Biener wrote: >> >>> Yeah, though this has interesting effects on includes that do stuff like >>> >>> #ifdef NO_DOLLARS_IN_LABELS >>> ... >>> >>> where the presence of this definition depends on another header file >>> and thus the ultimate outcome in your .c file depends on include file >>> order. >>> >>> So ... no #ifdefs inside headers? Or have meta-defines like >>> >>> #define NO_DOLLARS_IN_LABELS_DEFINED >>> >>> and >>> >>> #ifndef NO_DOLLARS_IN_LABELS_DEFINED >>> #error ... >>> #endif >>> >>> at use sites? >> >> Rather than such a meta-define, I prefer changing the semantics of the >> macro itself from defined/undefined to nonzero/zero, changing the users >> from #if to if () conditionals (or ? :, as appropriate), and adding a >> default zero definition to defaults.h along with updating all definitions, >> users and documentation. A meta-define seems just as error-prone as the >> original #ifdef. > > I like this a lot actually.... then you can tell whether its been defined or > not... Although I suppose it depends on when and where the non-default value > comes from, and that it is properly included in the .c file and not missed. > It ought to cover the vast majority of cases anyway. > >> >> Similarly, for any macros with default definitions scattered around the >> source tree rather than in defaults.h, moving them to defaults.h is a good >> idea. > > I think this is also a good idea.
Or you move the macros depending on NO_DOLLARS_IN_LABELS to tm.h itself ... Richard. > Andrew >
