[btw, my previous response didn't make the loop back to me, is that just me or is something stuck on the mailing list?]
On Wed, Feb 24, 2016 at 04:26:58PM +0000, Paul Jakma wrote: > Also, does this depend on using dynamic linking? We do have people who > like to build Quagga with --disable-shared at least (though, that still > results in an ELF binary dynamically linked). It's no problem, constructors work on statically linked binaries too. > > No -- moving memtypes into the files they're used in was also a major > > design goal, thus the existence of DEFINE_MTYPE_STATIC(). A table does > > not allow for that. > > You could have file specific groups. Looking at the changes in lib/, the average is 2.39 MTYPEs per file (only counting files that have MTYPE definitions). There are 33 such files. Every single file would not only need a group but also an initialisation function that is called from somewhere, without using constructors I guess. This sounds very finicky to me, but if you wanna cook up a patch I'm happy to review it... > > Considering that the linker functionality for constructors is > > neccessarily present on any architecture that supports C++ (this is > > how global variable classes get their constructors called), > > Right. Not everything supports C++ though. Not that Quagga.net supports > such platforms though. C++ is harder to bring up on weird platforms than > C though. > > The thing I have on my mind is embedding Quagga into non-standard, > non-Unix, relatively minimal runtimes, that might have their own > compiler or else do not have special support from GCC for their exe > format. More and more of these runtimes are springing into existence, > thanks to IoT and ultra-minimal "virtualisation" efforts. > > I used to sit beside someone who worked on that stuff, and they used to > have fun porting C code over. I don't see how this is relevant to the discussion on this patch set? If someone wants to start porting Quagga to IoT devices, they have much bigger problems than this patchset... heck, it's problematic to even get Quagga onto a low-flash (4 MB or 8 MB) OpenWRT device, and that's still Linux+gcc. Btw, 8-bit AVR supports gcc and constructors. It's one of the architectures that no-prologue-chains them. Same for Cortex-M ARMs, it's part of the linker magic, you don't even need an RTOS. > > Also, I have put considerable thought into making this as hard as > > possible to (accidentally) misuse, removing for example the > > possibility to forget initialisation calls. If someone forgets the > > DECLARE_MTYPE (or DEFINE_MTYPE_STATIC), they get a compiler error. > > If someone forgets the DEFINE_MTYPE, they get a linker error. Pass > > NULL as type and you get a warning from the "nonnull" attribute. I'm > > not saying it's impossible to misuse but it needs a special kind of > > stupid ;) > > Sure. > > It's cute. I must strongly object to the use of the diminutive word "cute" in this context. We live in an age of ubiquitous security vulnerabilities in all kinds of code. A lot of them are caused by improperly used interfaces, which in a lot of cases again is caused by a lack of safety features in interface (or language - yay C!) designs. Proper UX design, in this case from one developer providing an API to another developer, is a critical matter that must be valued appropriately. Even arguing that the memtypes API is probably not security critical is fallacious -- proper UX design needs to be pervasive, and to put it to the ridiculous extreme, even "just" a crashing Quagga instance at some ISP can cost the life of a person trying to make a VoIP 911 call. (Urgh, I hope not.) Using the word "cute" diminishes the value of the work I have done to produce an interface that pushes ease of use, difficulty to misuse and maintainability. It's an improvement in usability, and that's all it needs to be to have considerable impact and importance. The fact that the first patch in the series goes and fixes existing misuse of the old API illustrates this well enough. -David _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
