Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2002:
[Freeciv-Dev] Re: "division by zero" error during compilation (PR#1954)
Home

[Freeciv-Dev] Re: "division by zero" error during compilation (PR#1954)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: "division by zero" error during compilation (PR#1954)
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Sat, 7 Sep 2002 15:10:05 +0200

On Wed, Aug 21, 2002 at 12:16:33PM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> If I compile FreeCiv with gcc3 and -Werror, I get
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./include -I../common -I../intl 
> -I./agents     -g -O3 -Wpointer-arith -Wcast-align -Wmissing-prototypes 
> -Wmissing-declarations -Werror -g -Wall -c `test -f tilespec.c || echo 
> './'`tilespec.c
> cc1: warnings being treated as errors
> tilespec.c: In function `fill_tile_sprite_array_iso':
> tilespec.c:1269: warning: division by zero
> tilespec.c:1271: warning: division by zero
> make[3]: *** [tilespec.o] Error 1
> 
> this has also been reported as a problem (not sure if it's an error or 
> warning) under (IIRC) sun cc.
> 
> The "problem" is in the following code in tilespec.c:
> 
>   int array_index = ((ttype_near[DIR_CCW(dirs[i])] != T_OCEAN ? 1 : 0)
>                       + (ttype_near[dirs[i]] != T_OCEAN ? 2 : 0)
>                       + (ttype_near[DIR_CW(dirs[i])] != T_OCEAN ? 4 :
>                           0));
> 
> because DIR_CW and DIR_CCW have a possibile division by zero (if the 
> given direction is invalid, a division by zero is done to force an abort).
> 
> The simplest solution is to change the implementation of DIR_[C]CW so 
> that the (dir)/0 part becomes (assert(0),dir).  This has a secondary 
> advantage in that it won't crash the code when compiled with NDEBUG 
> (although the behavior of the program may become undefined afterwards). 
>  However, it is possible that some compilers might not like this 
> construct either (I have no problems with gcc3).
> 
> One alternative would be to just drop the assert() part completely; 
> however, I like checks like these and would be sorry to see that happen. 
>   Another would be to replace assert() with abort(); this would 
> preserve the current behavior (which, as I said, I think is a bad idea). 
>  Yet another would be to change the calling code to avoid this sort of 
> construct, but that's just a hack - and will make the already ugly 
> tilespec code even less pretty.
> 
> Patch attached.

Another suggestion: just make the code a real function. There is no
need for a macro. It isn't used often.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  (On the statement print "42 monkeys"+"1 snake"): BTW, both perl and Python
  get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when 
  the answer is clearly "41 monkeys and 1 fat snake".  
    -- Jim Fulton, 10 Aug 1999

Attachment: dir_cw1.diff
Description: Text document


[Prev in Thread] Current Thread [Next in Thread]