On Thu, 2009-07-23 at 21:51 +0200, Vladimir 'phcoder' Serbinenko wrote: > 2009/7/23 Javier Martín <lordhab...@gmail.com>: > > Here is a new version which also incorporates the C99 integer constant > > macros. To avoid excess verbosity, all macros have now names like Gx, > > where x is the standard name. Thus, PRIx64, UINT64_C(a) --> GPRIx64, > > GUINT64_C(a). > Please respect current convention of using GRUB_ as prefix for macros > Are the macros *_C really useful? Anyway it's to be discussed > separately. Could you not do increase previous patch bt make a new one > to separate what is already in discussion from new things. > @Pavel: do you have any further comments?
I believe it's not worth the trouble at this point. There are many patches that I make and never send or never commit because I'm not sure that the change is valuable enough. Every change comes with a risk of breaking something. For instance, I planned to remove "cli" in the bootloader, but decided that it's not worth the risk. I wanted to remove support for module unloading, but decided that there is a downside for users, and there are better ways to reduce the size of core.img. I wanted to simplify awk invocation, but decided not to pursue it at this time, as it would conflict with other efforts to reorganize the build system, and the benefits would be mostly theoretical. I think a good developer should be able to drop changes that are not exactly useful and move on. We have other issues. Javier mentioned -Wconversion. It makes the compiler very noisy, but some issues it found are real, such as the problem with ALIGN_UP. It's more important than pushing the same patch. One day we may find a nice solution to the issue of file formats. Maybe a new C standard appears with new format specifications. Maybe gcc will add some checks. But as it stands now, we won't benefit from it enough to justify less readable code. Let's move on and work on the issues where we can make the difference now. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
