http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631
--- Comment #6 from pebbles at riseup dot net --- You seem to be speaking from an assumption that this warning code should not change. Is there a reason for not adding this small patch, which makes gcc more extendable and accurate? (In reply to Georg-Johann Lay from comment #5) > The ISR macro is defined by AVR-LibC. It adds extern "C" to ISR if compiled > for C++. Thus, the handlers are not mangled and names like __vector_<num> > are used even if compiled for C++. > > Moreover, you should not use __vector_<num> firectly, use the support macros > from avr/io.h and avr/interrupt.h. They work for C++. If not, please file > a bug report against AVR-LibC. extern "C" does not work inside a class. I'm glad to file a bug report with AVR-LibC for this, but generally it is not expected that C macros work inside classes. The signal and interrupt attributes are described in the gcc attribute documentation. I would like to use them. I am trying to create a way for unknown code using my library to define event handlers. It's true, I can handle this "at runtime" by calling back to them from for example INT0_vect, relying on GCC to inline the call if it is known at compile time. If it is indeed known, it is more efficient and brings the user closer to the hardware to call it straight from the interrupt vector table, which can only be set up by the linker. Right now gcc restricts my interface specification in such a way that if I allow code to define a static event handler, and I want it to be an interrupt in the interrupt vector table, it must be named __vectorABC or declared with ISR(ABC_vect) and be file scoped. If things become more complex and this static event handler will be called from inside another interrupt handler, the ISR(ABC_vect) convention will no longer work; the interface specification and all code must be updated. If I can give the handler a non-AVR-LibC name, then all that needs to change is the attribute in the header file. Code becomes maintainable, and self-documenting too. I can do this right now, gcc just issues a warning if that name does not start with __vector. I do really appreciate as many alternative solutions as there are, but I am actually going to do this, warning or no, because I am trying to both accurately represent the hardware and abstract it. > >> You can name the function __vectorFOO or __vector_my_ISR_function or > >> whatever without raising a warning. > > > > But that requires reading the source of GCC, which I have begun doing but is > > usually not a prerequisite for coding. The warning should tell me that > > straight out. > > You should read the documentation of AVR-LibC, of course. You can add > documentation parts to the GCC documentation if you find it helpful. > However, users typically read the AVR-LibC manual because ISR and the vector > names are supplyied by AVR-LibC's av/io.h and avr/interrupt.h. As you state earlier, AVR-LibC does not intend us to be aware of the __vector_NN naming convention; I don't believe it's mentioned in the docs. Solving my problem by artificially prefixing my function names with __vector, which works but restricts what I can name them in an unpleasant way, involves finding the warning check in the GCC source to understand that that is a solution. This seems like a very small patch that makes GCC more extendable and accurate. I am not too attached to these things changing, although I am curious what the reason is for not considering the patch.
