RE: 64-bit analysis of the gtk+ library

["Shivram U" <shivaram upadhyayula wipro com>]

Hi Owen,
	Here are my observations based on the lint output.

The warnings can be classified in general as the following

1. Warnings due to return values of strlen() etc..
	These can be safely ignored. Its not possible for these values to exceed
the max size of an unsigned int.

2. Warnings due to the value of G_STRUCT_OFFSET being passed to
g_signal_new().
	    The macro G_STRUCT_OFFSET() casts the offset in the structure to a
glong, a 64-bit quantity. The warning arises because g_signal_new() expects
a value of type guint, a 32-bit quantity. These can be safely ingnored.

3. Warnings due to the macro definitions of GPOINTER_TO_UINT and
GPOINTER_TO_INT.
    The GPOINTER_TO_UINT and the GPOINTER_TO_INT macros provide a portable
method of storing gint and guint values in gpointer variables. The warning
arises because of the definition of the macros.
#define GPOINTER_TO_INT(p)      ((gint)  (glong) (p))
#define GPOINTER_TO_UINT(p)     ((guint) (gulong) (p))
    The cast from (gulong) to (guint) and (glong) (gint) results in the
warning. Not a problem though.

4. Warnings due to VisualIDs being treated as 32-bit quantities.
	Would VisualIDs exceed the max value of 2x32-1 (can we have so many
VisualIDs :-) ). If so then they may have to be fixed.

5. Warnings due to XIDs being treated as 32-bit quantities.
	Would these warnings have to be fixed ?

6. Warnings due to Atom values being treated as 32-bit quantities.
	Would these warnings have to be fixed.

7. Warnings due to pixel values being treated as 32-bit quantities.
	I guess these can be safely ignored.

8. Lastly use of g_signal_connect() and friends. The handler ids returned
are treated as 32-bit quantities, although they are of type gulong. Would
that cause problems?


Best Regards,
Shivram U

> -----Original Message-----
> From: gtk-devel-list-admin gnome org
> [mailto:gtk-devel-list-admin gnome org]On Behalf Of Owen Taylor
> Sent: Friday, July 05, 2002 9:21 PM
> To: Shivram U
> Cc: gtk-devel-list gnome org
> Subject: Re: 64-bit analysis of the gtk+ library
>
>
>
> "Shivram U" <shivaram upadhyayula wipro com> writes:
>
> > 	I have generated the lint output of the gtk+ library for a 64-bit
> > compilation environment. Would anyone be interested in the
> same. This would
> > be useful in debugging potential 64-bit problems in a 64-bit
> environment.
>
> If there are actual problems found by the lint output, we'd, of
> course, be interested, and they should be filed in bugzilla but I don't
> think we are particularly interested in the full output.
>
> The general policy is that for GTK+/GDK/Pango we are not interested in
> "problems" of the nature:
>
>  int foo = strlen (string);
>
> unless there is some probability that the string could actually
> usefully have 2 billion characters in it, and casts to suppress
> 64-bit lint warnings:
>
>  int foo = (int)strlen (string);
>
> Are also not really acceptable, since they make the code much
> more visually cluttered.
>
> (We did go through and fix up GLib to be clean in the use
> of size_t where necessary)
>
> Also, no API changes that involve changing the width of arguments
> can be made at this point.
>
> (http://bugzilla.gnome.org/show_bug.cgi?id=56652 is a GTK+ bug that
> was filed in this area earlier; the corresponding GLib bug is:
> http://bugzilla.gnome.org/show_bug.cgi?id=53764.)
>
> Regards,
>                                         Owen
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>