Re: gssize, gsize

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 6 Jun 2000, Federico Mena Quintero wrote:
> 
> > Owen Taylor <otaylor@redhat.com> writes:
> > 
> > > Currently, glib.h has
> > > 
> > >  #define gint32 gssize
> > >  #define guint32 gsize
> > > 
> > > This strikes me as a bad idea. On a 64 bit platforms, attempts to 
> > > use these in place of ssize_t and size_t are going to produce warnings
> > > and, in extreme cases, incorrect code.
> > > 
> > > If we don't want to simply include <stddef.h> and use size_t and ssize_t,
> > > which strikes me as the right course. We should test for the sizes of
> > > these types and mirror that in gssize and gsize.
> > > 
> > > Right?
> > 
> > We should just use size_t and ssize_t.
> 
> no, except for void, we use only g/G prefixed types in glib's API and
> implementation and i don't remember agreeing to change that.

 #define gconst const
 #define gwhile while
 #define gif if

GThis gtendency gcan go gto gfar.

While I've come to believe that gint, gchar were bad ideas, I've been
willing to keep them for the sake of tradition.

I don't think that means we have to keep on sticking a g in front of
_everything_.

A C programmer should know what size_t means. gsize requires them to
learn something new for no good reason. In fact, since it isn't gsize_t,
it isn't even guessable what it will be. It can't be claimed that
there is a parallelism between:

 int => gint
 size_t => gsize

Regards,
                                        Owen