qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Purge the silly GLib Basic Types


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/3] Purge the silly GLib Basic Types
Date: Mon, 21 Jan 2013 16:43:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Michael Tokarev <address@hidden> writes:
>
>> 19.01.2013 13:33, Blue Swirl wrote:
>>> On Fri, Jan 18, 2013 at 4:17 PM, Anthony Liguori
>>> <address@hidden> wrote:
>>>> Markus Armbruster <address@hidden> writes:
>>>>
>>>>> See PATCH 1/3 for rationale.
>>>>>
>>>>> Markus Armbruster (3):
>>>>>    Purge the silly GLib "Basic Types", except for gboolean
>>>>>    Purge GLib's gboolean, it's a trap for the unwary
>>>>>    checkpatch: Keep out the GLib silliness we just purged
>>>>
>>>> Changing QEMU code to work around checkpatch's failing is insane.
>>>>
>>>> When interacting with glib, use glib types.  Not using those types just
>>>> makes the code more difficult to understand.
>>>
>>> While the types are indeed useless and even cause problems (gboolean),
>>> I agree with Anthony. It's the same as using DWORD for Win32 APIs.
>>
>> Actually it is far from DWORD.  DWORD is like uint32_t, where no
>> standard C type matches (since these depends on the word size etc).
>> So in Win32, these DWORDs are justified.
>>
>> With GLib, things are sillier than that, since they redefine _standard_
>> C types, without gaining anything in portability.
>
> glib predates "standard C types".  They were only introduced in C99 and
> weren't widely available until a few years later.
>
> There are reasons for all of it.  For instance, there was a time when
> not all C compilers supported const so if you wanted to use it you had
> to #define around it.  gconstpointer was a trick to make use of const
> while still supporting older compilers.  Likewise, bool is a relatively
> new thing so gboolean made sense at the time.  The lack of stdint led to
> g[u]int{8,16,32,64} and once you have all of that, gint and guint are
> pretty obvious.

The sane thing to do is to deprecate the crap that ceased to make sense
years ago and move on.

Of course you keep the typedefs and macros forever for the benefit of
existing users.  Just don't use them in the API, or its implementation.

> We should not use these types pervasively in QEMU, of course preferring
> more modern standard C99, but when glib takes a callback of:
>
> gboolean (*GSourceFunc)(gpointer data)
>
> Then the most readable thing to do is to write your callback following
> that signature.

Readibility is in the eye of the beholder.

If you want them used in this limited role, I can live with it.
Unfortunately, automated defense against them creeping beyond the limit
doesn't look feasible.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]