From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC, PATCH] C99 format specifiers for fixed-length integer types
Date: Thu, 23 Jul 2009 16:16:08 -0400 [thread overview]
Message-ID: <1248380168.2661.71.camel@mj> (raw)
In-Reply-To: <d7ead6de0907231251j44a790c2k54e93d970abc21b3@mail.gmail.com>
On Thu, 2009-07-23 at 21:51 +0200, Vladimir 'phcoder' Serbinenko wrote:
> 2009/7/23 Javier Martín <lordhabbit@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
next prev parent reply other threads:[~2009-07-23 20:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-22 19:10 [RFC,PATCH] C99 format specifiers for fixed-length integer types Javier Martín
2009-07-23 1:08 ` Pavel Roskin
2009-07-23 2:03 ` Javier Martín
2009-07-23 2:31 ` Pavel Roskin
2009-07-23 18:54 ` Javier Martín
2009-07-23 19:51 ` [RFC, PATCH] " Vladimir 'phcoder' Serbinenko
2009-07-23 20:16 ` Pavel Roskin [this message]
2009-07-23 20:38 ` Vladimir 'phcoder' Serbinenko
2009-07-23 21:25 ` Javier Martín
2009-07-23 21:48 ` Pavel Roskin
2009-07-25 15:14 ` Javier Martín
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1248380168.2661.71.camel@mj \
--to=proski@gnu.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.