[Bf-committers] Compile warnings

bjornmose bjornmose at gmx.net
Fri Sep 16 02:14:53 CEST 2005


Ton Roosendaal wrote:
> Hi,
> 
> There's a couple of compiler warnings in last week's commits. Like  
> usage of not prototyped functions, unused vars, unitialized vars. Easy  
> to fix, will commit it myself. However, there's issues in Font,  
> Edgeslide and Imagepaint I like to note:
> 
> - Font stuff:
> If a wchar_t is an unsigned short, then this line cannot work:
> 
> scr/editfont.c, line 1123
>     cu->len= strlen(textbuf);
> 
> Since textbuf became wchar_t. Dunno the proper strlen version for this.
> 
> Then it looks like new code uses spaces instead of tabs. (interface.c,  
> editfont.c). Should really be fixed! And follow code style of existing  
> code.
> 
> The ui_do_but_CHARTAB() in interface.c is not a nice way to do it...  
> this could be solved using existing button callbacks. Having editmode  
> text code inside the core interface is not nice. Same goes for the  
> drawing version of the button. Buttons should really serve more generic  
> purposes. :)
> I might check on that or help with it later.
> 
> Then there's six new globals, like G.selfont... is that really needed?
> 
> - EdgeSlide:
> Johnny please check my commit-diff for editmesh_tools.c. The way  
> variables are calculated are a bit confusing. My fixes are probably  
> right, but check if the initialized values are correct!
> 
> - ImagePaint
> The code added in headerimage.c is very messy. At least follow a bit  
> the C convention as used in the rest of the file. Further I don't  
> advise to use the old clever_numbut code anymore...
> then there's a global array written with capitals (UVTEXTTOOL_DATA),  
> and I really don't get why all these globals are needed in  imagepaint.c...
> In space.c you use calls from imagepaint.c without prototypes.
> 
> This could have used a good code review before added, and poking people  
> who like to design button panels. Seems like much wanted functionality  
> yes, but worth checking on a good integration to make it future proof.  :)
> 
> -Ton-
> 
> ------------------------------------------------------------------------ --
> Ton Roosendaal  Blender Foundation ton at blender.org  http://www.blender.org
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 
> 
Hi ton,
totally argree,
This is why put 2D UV painting ( aka imagepaint )to patch tracker first.
I even pointed out some weak points you're complaining about now.
Especially global vars.
.. 
https://projects.blender.org/tracker/index.php?func=detail&aid=2866&group_id=9&atid=127
..
But i never got any usefull feedback on how to do it better.
Asking brecht (don't want to blame him at all) resulted in 'commit and 
see' so .. i don't mind to roll back the whole thing and do it right.
Only i don't have a faint idea what is supposed to be *right*.
/* beeing scientist and  C++ coder who likes standard template libs 
(STL) makes me quilty 'per se' and i apologize for that. */

about headerimage.c
is the *mess* declaring local vars ? ( easy to fix )

about use of clever_numbut code .. never really liked it .. but how to 
get 'user input' for some numbers needed for creation process ( 
preferably remembering last input ) ...

and so on
hmm .. but if someone would have looked at the patch ..
.. sigh ..
BM






More information about the Bf-committers mailing list