On Fri, Jul 27, 2012 at 10:40 PM, Anthony Liguori <aligu...@us.ibm.com> wrote: > Blue Swirl <blauwir...@gmail.com> writes: > >> On Fri, Jul 27, 2012 at 8:51 PM, Anthony Liguori <aligu...@us.ibm.com> wrote: >>> If someone comes along and actively maintains support for another >>> compiler, we can revisit. But otherwise, there's no practical reason to >>> avoid extensions. >> >> Because it's more compliant to standards. > > That is not a benefit. There is no practical advantage to sticking to > only C99. > > If we stuck to C99 only, QEMU would look very different. We wouldn't > have type_init() so we wouldn't have the module system we use today. > It literally took me months to get those patches merged because Paul > made exactly the same argument you're making now. > > And it's really been one of the better cleanups in QEMU that we've ever > done (using modules to define devices).
Yes, it's a very nice cleanup. But I'm not saying things like that would have to be changed much or at all. As an example for type_init(), a script could grep and process those declarations (like the recently posted IDL stuff) and generate type tables in a .c file for the non-GCC compiler. Then an initialization function would just call the functions in the table in sequence. That way GCC can use initializers but with clever hacks, non-GCC compilers can be used too. > >> There's also very little benefit from using the nonessential >> extensions. > > Using weak symbols eliminates #ifdefs and makes the code base a lot > cleaner. It makes it easier to introduce architecture specific hooks in > a clean way. > > Considering how messy a lot of our target-specific code is, I think > there could be quite a significant benefit down the road. I don't have anything specifically against weak symbols, probably with macros like QEMU_WEAK() they can also be accommodated later if ever needed. Just offhand, the macro could also take a symbol prefix which is ignored for GCC, but used in non-GCC case to create a table which a symbol resolver (not compiled in for GCC) would use. > > Regards, > > Anthony Liguori > >> >>> >>> Regards, >>> >>> Anthony Liguori >>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Anthony Liguori >>>>> >>>>> >>>>>> -- if I >>>>>> write a patch which is pretty much standard C then it's the >>>>>> platform's problem if it mishandles it. If I write a patch >>>>>> that uses a compiler-specific or OS-specific thing then I >>>>>> have to also provide the relevant alternatives...so I try >>>>>> to avoid doing that :-) >>>>>> >>>>>> -- PMM >>>>> >>>>> >>> >