I think we are in agreement then. Acked-by: Donald Sharp <[email protected]
On Wed, Feb 24, 2016 at 1:50 PM, David Lamparter <[email protected]> wrote: > [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 > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
