Re: [PATCH] ANSI C correctness + warning fixes

[Tim Janik <timj gtk org>]

On 9 Oct 2000 otaylor redhat com wrote:

> 
> Tim Janik <timj gtk org> writes:
> 
> > On 4 Oct 2000 otaylor redhat com wrote:
> > 
> > > 
> > > Martin Baulig <martin home-of-linux org> writes:
> > > 
> > > > otaylor fresnel labs redhat com writes:
> > > > 
> > > > > Please change gtk_selection_data_get/set_text to take gchar *.
> > > > 
> > > > What about GtkSelectionData and gdk_utf8_*() ?
> > > 
> > > GtkSelectionData should remain a guchar *, gdk_utf8_* should
> > > be gchar * if it guchar * now.
> > > 
> > > Basically, the convention we have is thet gchar * is used for
> > > text and guchar * for blocks of uninterpreted data.
> > 
> > nope, that'd be guint8/gint8 depending on whether you work
> > with signed/unsigned byte blocks.
> 
> Can you provide an example of this? I can't and can find plentiful
> examples of guchar usage.

the most obvious one is probably g_byte_array(), there are others.

> It wouldn't make much sense either - C guarantees sizeof(char) == 1,
> so gchar, guchar is perfect for 'a block of bytes'.

right, so lets declare GtkWidget in terms of a guchar array.
the point here is not to be "more C conformant" but to write more
expressivce code. and the resoning is perfectly sound, *char is used
for characters, e.g. to form strings, while *int{8|16|32|64} is an
integer type that carries its bit widths in its type name.

> The only place I can think of using gint8 is in something like
> gdk_gc_set_dashes - where we have something which is an integer-valued
> parameter whose range is restricted to 8 bits.

well, you don't _have_ to use gint8, as you said, gchar works quite as well.
usage of gint8*/guint8* over gchar*/guchar* is just preferrable where
applicable, that is operations aren't done on strings, but byte arrays
(or blocks thereof).
for such code i can e.g. tell that embedded 0s aren't special cased and
the like.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ