Re: [RFC, PATCH] C99 format specifiers for fixed-length integer types

[Vladimir 'phcoder' Serbinenko]

On Thu, Jul 23, 2009 at 10:16 PM, Pavel Roskin<address@hidden> wrote:
> On Thu, 2009-07-23 at 21:51 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> 2009/7/23 Javier Martín <address@hidden>:
>> > 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.
I also agree that *_C macros are not very useful and make code less
readable however I want to let JAvier speak why he wants this in GRUB
>
> 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.
>
There is also -Wdeclaration-after-statement which reports style
problems. I have currently a branch named nomixed which fixes all
these parts but may introduce bugs
> 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.
>
Ok. Let's look at video subsystem? My framebuffer changes are
necessary to get graphics support on EFI-based platforms (including
GOP). I know it's big but it's mostly moving the code around and
benefit would be easy implementation of new graphical drivers. Then we
could merge Collin D Benett's patches as much as is already ready to
go in
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git