[GRASS-dev] Re: [GRASS GIS] #771: use longer ints for counting raster cells

GRASS GIS trac at osgeo.org
Thu Oct 1 14:05:11 EDT 2009


#771: use longer ints for counting raster cells
---------------------+------------------------------------------------------
  Reporter:  hamish  |       Owner:  grass-dev at lists.osgeo.org
      Type:  task    |      Status:  new                      
  Priority:  normal  |   Milestone:  6.4.0                    
 Component:  Raster  |     Version:  svn-develbranch6         
Resolution:          |    Keywords:  overflow                 
  Platform:  All     |         Cpu:  Unspecified              
---------------------+------------------------------------------------------
Comment (by glynn):

 Replying to [ticket:771 hamish]:

 > r.info man page:
 {{{
 Some standards (ISO-C90) and compilers do not support the 'long long' type
 as a 64-bit type.
 }}}

 Just to clarify: C89 doesn't support it at all; the compiler will report a
 syntax error if the code contains "long long".

 > we should standardize on something. any reason not to make it unsigned?

 For counts, using an unsigned type makes sense. Using "unsigned long" will
 at least give you 64-bit values on 64-bit systems.

 One caveat is that comparing signed and unsigned values will cast the
 signed value to an unsigned value, which results in undefined behaviour if
 the signed value is negative. So you need to use e.g.:

 {{{
         if (sval < 0 || (unsigned) sval < uval) ...
         if (sval < 0 || (unsigned) sval <= uval) ...
         if (sval >= 0 && (unsigned) sval == uval) ...
         if (sval >= 0 && (unsigned) sval >= uval) ...
         if (sval >= 0 && (unsigned) sval > uval) ...
 }}}

 to ensure that the signed-unsigned comparison is only performed when the
 signed value is non-negative.

 Another caveat is the difference between two arbitrary unsigned values
 cannot be represented by the equivalent signed type.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/771#comment:1>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list