>
> It should generally be opaque to the user that gsize is not
> a typedef for size_t, so you could definitely define it that way for
> the LSB. However, you'd need to include a footnote to the effect:
>
> 1) This definition should not be taken to imply that including
> glib.h necessarily i
On Thu, 2006-02-09 at 16:53 -0800, Banginwar, Rajesh wrote:
> >
> > What we try to do is to to match the type of size_t on the system;
> > for 64-bit platforms, that isn't really a problem ... size_t will
> > be 'unsigned long', but on 32-bit platforms it could either by
> > 'unsigned int' or 'uns
>
> What we try to do is to to match the type of size_t on the system;
> for 64-bit platforms, that isn't really a problem ... size_t will
> be 'unsigned long', but on 32-bit platforms it could either by
> 'unsigned int' or 'unsigned long'.
>
So, on 32 bit platforms, why not typedef it as 'unsig
On Thu, 9 Feb 2006 10:23:06 -0500 (EST)
[EMAIL PROTECTED] (Morten Welinder) wrote:
> But, yes, glib uses non-standard C in lots of ways, this just being
> one of them.
That said, so does POSIX. E.g. C99 does not require that a void* can hold
a function pointer, but POSIX does.
--
Paul "LeoNer
> size_t and ssize_t are supposed to be usable to hold pointer values
> without loss
Eh?
>From C99, Section "6.3.2.3 Pointers":
[#6] Any pointer type may be converted to an integer type.
Except as previously specified,theresultis
implementation-defined.
On Wed, 2006-02-08 at 18:39 -0800, Banginwar, Rajesh wrote:
> Hello,
> For IA32 gsize (found in glibconfig.h) is defined as: typedef
> unsigned int gsize;
> For IA32-64bit extn and IA64 (Itanium) the definition is:
> typedef unsigned long gsize;
>
> Is this intentional? The documentat
On Wed, 8 Feb 2006, Banginwar, Rajesh wrote:
Hello,
For IA32 gsize (found in glibconfig.h) is defined as: typedef
unsigned int gsize;
For IA32-64bit extn and IA64 (Itanium) the definition is:
typedef unsigned long gsize;
Is this intentional? The documentation does not mention an
It seems like from this long thread that what's needed is not
native GTK+ for OS X, but rather a binary distribution of native
GTK+ for OS X...
But if it runs on only 10.4, then you are out of the game anyway.
Hub
___
gtk-devel-list mailing list
gt
