RE: Typedef inconsistency for gsize and gssize

[Owen Taylor <otaylor redhat com>]

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 'unsigned long'.
> > 
> 
> So, on 32 bit platforms, why not typedef it as 'unsigned long'? Should
> LSB do that (as it applies only to Linux systems so far)?

I believe size_t is unsigned int on 32-bit Linux ...

> > (Matching the type prevents certain warnings when passing a size_t
> > to a function expecting a gsize or vice-versa.)
> > 
> > So, the most accurate definition you could give is
> > 'typedef gsize size_t', except that glib.h does *not* include
> > stddef.h so it's not literally that in the header files.
> 
> Is that an option then? What was the reason for not including stddef
> explicitely?

The Glib policy is to avoid pulling in system headers, because they
become part of the API ... that is, say you include stdlib.h in
a header file ... you can never remove it.

Avoiding including system headers avoids a whole class of potential
compatibility headaches.

Of course, applying that policy to stddef.h is arguably going to
far... But that's the policy we've tried to stick to.

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 includes stddef.h.

Regards,
					Owen