Re: GLogLevelFlags enum and g_log

[Umut Tezduyar Lindskog <umut tezduyar com>]

Hi Simon,

Thanks taking the time and explaining things in detail.

On Mon, May 26, 2014 at 11:59 AM, Simon McVittie
<simon mcvittie collabora co uk> wrote:
> On 24/05/14 17:59, Umut Tezduyar Lindskog wrote:
> > Normally it shouldn't be a problem but since glib defined values of
> > GLogLevelFlags can fit in to 8 bits, sizeof(GLogLevelFlags) could be 1
> > depending on the compiler.
>
> My understanding is that GLib (and particularly GObject) has a general
> architectural assumption that, in the compiler's target ABI, all
> non-bitfield enums that could fit in an int are the size of an int (and
> in particular, no smaller). What compilers, platforms, ABIs that don't
> make this true do you have in mind?

I haven't tried any such compiler on glib but I have seen in house
compilers that pack structs.

> If this is the case, then it would seem wise to add something like
>
>     G_STATIC_ASSERT (sizeof (enum { A = 1 }) == sizeof (int));

I think this is a great idea. I believe the check can even be a
preprocess directive. Would you like to get this check happen in glib
or do you think clients should add the check on their side?

Umut

> to check this assumption.
>
> In practice, if the compiler assigns enums' sizes according to their
> defined values, you can't add elements to the end of an enum without
> breaking ABI, unless you include a placeholder value to reserve space.
> Consider this hypothetical library:
>
>     /* libfoo v1 */
>     typedef struct {
>         enum { E1 = 1, ..., E255 = 255 } e;
>         char c;
>     } Foo;
>
>     /* libfoo v2 */
>     typedef struct {
>         enum { E1 = 1, ..., E255 = 255, E256 = 256, ... } e;
>         char c;
>     } Foo;
>
>     /* application code */
>     Foo *my_foo;
>     printf ("%c", my_foo.c);
>
> (Realistically, e could be an error code that is intended to be extended
> over time as more potential error situations are discovered, like
> GIOErrorEnum.)
>
> Compile and link the application code dynamically against libfoo v1, and
> then upgrade to libfoo v2. If the compiler made the first version of
> Foo.e 1 byte long, then the access to my_foo.c would essentially compile
> to ((char *) my_foo)[1]. When upgraded to libfoo v2, it would
> incorrectly return the second byte of my_foo.e instead (and sizeof(Foo)
> would change, causing further ABI breakage for any struct that contains
> a Foo as a member).
>
> More generally, I think it's fine that GLib has architectural
> assumptions that make it portable to all relevant compilers and ABIs
> (GNU/*, Android, other Linux libcs, *BSD, Darwin/Mac OS/iOS, Windows,
> etc.) while not being portable to theoretical pathological ISO C
> implementations. However, where possible it would be good to have static
> assertions (G_STATIC_ASSERT) or regression tests that document those
> assumptions in an automatically-checkable way.
>
> Some other departures from ISO C that I am aware of:
>
> * ISO C does not guarantee that null pointer constants are
>   all-bits-zero, or that there is only one representation of a null
>   pointer. GLib assumes that there is exactly one representation of a
>   null pointer, NULL, and that it is all-bits-zero.
>
> * ISO C does not guarantee that signed integers use twos-complement for
>   negative numbers - they are allowed to use sign-and-magnitude or some
>   even weirder representation. There is almost certainly code in GLib
>   that assumes that they do use twos-complement.
>
> * ISO C does not guarantee that 8-, 16-, 32- and 64-bit types exist
>   (only that *if they do*, int8_t etc. are defined appropriately).
>   GLib assumes that they do exist; it probably also assumes that
>   char, short, int are exactly 8, 16, 32 bits respectively, and that
>   long is either 32 or 64 bits.
>
> * ISO C does not guarantee that data pointers (e.g. void *) have the
>   same size and representation as function pointers (e.g.
>   void (*) (void)), or even that all function pointers are the same
>   size/representation. GLib assumes that data pointers and function
>   pointers are both basically integers of equal size, so you can cast
>   freely between them. According to Linux dlopen(3), POSIX.1-2013
>   basically also requires GLib's interpretation, so it has probably
>   always been true in practice on Unix platforms.
>
> Regards,
>     S
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list