Message ID | 1312808190-31074-1-git-send-email-avi@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 08/08/2011 07:56 AM, Avi Kivity wrote: > QEMU deals with a lot of fixed width integer types; their names > (uint64_t etc) are clumsy to use and take up a lot of space. > > Following Linux, introduce shorter names, for example U64 for > uint64_t. Except Linux uses lower case letters. I personally think Linux style is wrong here. The int8_t types are standard types. Besides, we save lots of characters by using 4-space tabs instead of 8-space tabs. We can afford to spend some of those saved characters on using proper type names :-) Regards, Anthony Liguori > > Signed-off-by: Avi Kivity<avi@redhat.com> > --- > qemu-common.h | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/qemu-common.h b/qemu-common.h > index 0fdecf1..52a2300 100644 > --- a/qemu-common.h > +++ b/qemu-common.h > @@ -112,6 +112,15 @@ static inline char *realpath(const char *path, char *resolved_path) > int qemu_main(int argc, char **argv, char **envp); > #endif > > +typedef int8_t S8; > +typedef uint8_t U8; > +typedef int16_t S16; > +typedef uint16_t U16; > +typedef int32_t S32; > +typedef uint32_t U32; > +typedef int64_t S64; > +typedef uint64_t U64; > + > /* bottom halves */ > typedef void QEMUBHFunc(void *opaque); > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/08/2011 04:00 PM, Anthony Liguori wrote: > On 08/08/2011 07:56 AM, Avi Kivity wrote: >> QEMU deals with a lot of fixed width integer types; their names >> (uint64_t etc) are clumsy to use and take up a lot of space. >> >> Following Linux, introduce shorter names, for example U64 for >> uint64_t. > > Except Linux uses lower case letters. > > I personally think Linux style is wrong here. The int8_t types are > standard types. > > Besides, we save lots of characters by using 4-space tabs instead of > 8-space tabs. We can afford to spend some of those saved characters > on using proper type names :-) > It's not about saving space, it's about improving readability. We have about 21k uses of these types, they deserve short names.
On 08/08/2011 08:12 AM, Avi Kivity wrote: > On 08/08/2011 04:00 PM, Anthony Liguori wrote: >> On 08/08/2011 07:56 AM, Avi Kivity wrote: >>> QEMU deals with a lot of fixed width integer types; their names >>> (uint64_t etc) are clumsy to use and take up a lot of space. >>> >>> Following Linux, introduce shorter names, for example U64 for >>> uint64_t. >> >> Except Linux uses lower case letters. >> >> I personally think Linux style is wrong here. The int8_t types are >> standard types. >> >> Besides, we save lots of characters by using 4-space tabs instead of >> 8-space tabs. We can afford to spend some of those saved characters on >> using proper type names :-) >> > > It's not about saving space, it's about improving readability. We have > about 21k uses of these types, they deserve short names. This is one of the few areas that we're actually consistent with today. Introducing a new set of types will just create inconsistency. Most importantly, these are standard types. Every modern library and C program should be using them. TBH, having short names is just a bad case of NIH. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8 August 2011 13:56, Avi Kivity <avi@redhat.com> wrote: > QEMU deals with a lot of fixed width integer types; their names > (uint64_t etc) are clumsy to use and take up a lot of space. > > Following Linux, introduce shorter names, for example U64 for > uint64_t. Strongly disagree. uint64_t &c are standard types and it's immediately clear to a competent C programmer what they are. Random qemu-specific funny named types just introduces an unnecessary level of indirection. We only just recently managed to get rid of the nonstandard typenames for these from fpu/... -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/08/2011 04:17 PM, Anthony Liguori wrote: > > This is one of the few areas that we're actually consistent with > today. Introducing a new set of types will just create inconsistency. > > Most importantly, these are standard types. Every modern library and > C program should be using them. TBH, having short names is just a bad > case of NIH. > Those are exactly the same types, compatible with all the libraries. NIH would be redefining them ourselves (and breaking pointer compatibility etc.)
Am 08.08.2011 15:00, schrieb Anthony Liguori: > On 08/08/2011 07:56 AM, Avi Kivity wrote: >> QEMU deals with a lot of fixed width integer types; their names >> (uint64_t etc) are clumsy to use and take up a lot of space. >> >> Following Linux, introduce shorter names, for example U64 for >> uint64_t. > > Except Linux uses lower case letters. > > I personally think Linux style is wrong here. The int8_t types are > standard types. I fully agree, we should use the standard types. > Besides, we save lots of characters by using 4-space tabs instead of > 8-space tabs. We can afford to spend some of those saved characters on > using proper type names :-) Heh, I like this reasoning. :-) Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 8 Aug 2011, Peter Maydell wrote: > On 8 August 2011 13:56, Avi Kivity <avi@redhat.com> wrote: > > QEMU deals with a lot of fixed width integer types; their names > > (uint64_t etc) are clumsy to use and take up a lot of space. > > > > Following Linux, introduce shorter names, for example U64 for > > uint64_t. > > Strongly disagree. uint64_t &c are standard types and it's > immediately clear to a competent C programmer what they are. > Random qemu-specific funny named types just introduces an > unnecessary level of indirection. > > We only just recently managed to get rid of the nonstandard > typenames for these from fpu/... > Seconded.
Peter Maydell <peter.maydell@linaro.org> wrote: > On 8 August 2011 13:56, Avi Kivity <avi@redhat.com> wrote: >> QEMU deals with a lot of fixed width integer types; their names >> (uint64_t etc) are clumsy to use and take up a lot of space. >> >> Following Linux, introduce shorter names, for example U64 for >> uint64_t. > > Strongly disagree. uint64_t &c are standard types and it's > immediately clear to a competent C programmer what they are. > Random qemu-specific funny named types just introduces an > unnecessary level of indirection. > > We only just recently managed to get rid of the nonstandard > typenames for these from fpu/... Agreed. And if we want to change them to be "linux-like", can we just use the linux names? Using a name with uppercase just looks doubly wrong on my eyes. Later, Juan. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/qemu-common.h b/qemu-common.h index 0fdecf1..52a2300 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -112,6 +112,15 @@ static inline char *realpath(const char *path, char *resolved_path) int qemu_main(int argc, char **argv, char **envp); #endif +typedef int8_t S8; +typedef uint8_t U8; +typedef int16_t S16; +typedef uint16_t U16; +typedef int32_t S32; +typedef uint32_t U32; +typedef int64_t S64; +typedef uint64_t U64; + /* bottom halves */ typedef void QEMUBHFunc(void *opaque);
QEMU deals with a lot of fixed width integer types; their names (uint64_t etc) are clumsy to use and take up a lot of space. Following Linux, introduce shorter names, for example U64 for uint64_t. Signed-off-by: Avi Kivity <avi@redhat.com> --- qemu-common.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)