Re: fun project!



Thus spake Havoc Pennington:
> Nils Barth <nbarth@fas.harvard.edu> writes: 
> > So I just go through gtk/*.h, and every time I see a gint as a return
> > value/parameter value, I check .c to make sure it's appropriate
> > (doesn't only return/test for TRUE/FALSE), and if necessary change to
> > gboolean, respecting indentation.
> > 
> 
> Yep. Also, if you change a function declaration in .h, change the
> corresponding function definition in .c. 

Right; also, there were a few places where a struct stored a boolean
variable as a guint, which I changed to gboolean.
Is this okay, and should I also go through and check all guint's to
make sure they're not a boolean?

> > I made a very few gint -> gboolean changes to static functions and local
> > variables; should I revert these back/start over, or are these changes okay?
> > 
> 
> I guess they're fine, maybe Owen or Tim would object. You can always
> leave them for now and see if anyone dislikes them when you send the
> final patch.

Okay; these were pretty minor.

Please find the patch to convert gint -> gboolean in lots of places:
http://www.fas.harvard.edu/~nbarth/gboolean.patch

Two questions:
(1) (above) I mostly just inspected gint's, though sometimes I came
    across guint's that should be gboolean's -- should I
    systematically check guint's as I did with gint's?
(2) In gtkprogress.c, I changed some (BOOLEAN != 0) to (BOOLEAN !=
    FALSE), though couldn't this just be (BOOLEAN)?
    Also, in gtkmenuitem.c, I changed two (BOOLEAN == TRUE) to
    (BOOLEAN). Is this okay?
    In both these cases, it seem that this was a way of casting a gint
    to gboolean without saying so...and this pattern recurs, though
    sometimes it is != FALSE, other times it is == TRUE; are these
    necessary, and if so, should there be a GINT_TO_GBOOLEAN
    macro/function to do this?

-- 
  -nils
Public key: http://www.fas.harvard.edu/~nbarth/pub-key.txt



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]