[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