[GRASS-dev] Re: [GRASS GIS] #469: raster data needs binary mode on windows

GRASS GIS trac at osgeo.org
Thu Jan 29 15:57:22 EST 2009


#469: raster data needs binary mode on windows
---------------------------+------------------------------------------------
  Reporter:  jef           |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  major         |   Milestone:  6.4.0                    
 Component:  default       |     Version:  6.4.0 RCs                
Resolution:                |    Keywords:                           
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------
Comment (by glynn):

 Replying to [comment:3 warmerdam]:

 > Dear grass team.  I would humbly submit that making anyone who wants to
 use the grass libraries also link with fmode.o is risky and that it would
 be safer to actually enforce binary behavior at the open() call(s).  In
 other packages my practice has been to always pass O_BINARY to open(), and
 to predefine it to zero if it isn't already defined.

 Note: setting _fmode is the only way to get stdin/stdout into binary mode
 (we don't care about stderr). At least, this used to be the case. It
 appears that later versions of MSVCRT require that you explicitly change
 the mode of these descriptors. However, MinGW always links against
 msvcrt.dll, not a later version.

 BTW, I count 52 occurrences of open() or open64() in GRASS, including 6 in
 libgis and 6 in other libraries.

 I don't know how this affects other functions which create descriptors,
 e.g. pipe(), dup2(), etc. Putting "_fmode = O_BINARY" into gisinit() may
 suffice for everything except stdin/stdout; that would be preferable to
 requiring each case to be handled explicitly.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/469#comment:5>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list