Patchwork Introduce short names for fixed width integer types

login
register
mail settings
Submitter Avi Kivity
Date Aug. 8, 2011, 12:56 p.m.
Message ID <1312808190-31074-1-git-send-email-avi@redhat.com>
Download mbox | patch
Permalink /patch/108905/
State New
Headers show

Comments

Avi Kivity - Aug. 8, 2011, 12:56 p.m.
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(-)
Anthony Liguori - Aug. 8, 2011, 1 p.m.
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);
>
Avi Kivity - Aug. 8, 2011, 1:12 p.m.
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.
Anthony Liguori - Aug. 8, 2011, 1:17 p.m.
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
Peter Maydell - Aug. 8, 2011, 1:19 p.m.
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
Avi Kivity - Aug. 8, 2011, 1:19 p.m.
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.)
Kevin Wolf - Aug. 8, 2011, 2:17 p.m.
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
malc - Aug. 9, 2011, 10:18 a.m.
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.
Juan Quintela - Aug. 9, 2011, 12:39 p.m.
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.

Patch

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);