Opened 9 years ago
Closed 9 years ago
#6094 closed defect (fixed)
Return values of type OGRErr being set to -1, which is not in the list of defines
Reported by: | Kurt Schwehr | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.1.0 |
Component: | default | Version: | svn-trunk |
Severity: | normal | Keywords: | OGRErr |
Cc: |
Description
OGRErr has OGRERR_NONE as 0 for no error, but some functions/methods are using -1
as the no error case. It sucks that OGRErr is not an enum to catch this, but this is a pretty surprising return value. Changing OGRErr to an enum seems like something that is too big for GDAL 2.0.0 -> GDAL 2.1.0, so do we change the -1
returns to
OGRERR_NONE
or make another define of OGRERR_EVEN_MORE_NONE -1? And there are alternative meanings of -1
, like processing must continue.
- source:trunk/gdal/ogr/ogr_core.h@28900#L285
- source:trunk/gdal/ogr/ogrgeometry.cpp@29947#L4969 - success is
-1
- source:trunk/gdal/ogr/ogrgeometry.cpp@29947#L1215 - more processing is
-1
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
comment:3 by , 9 years ago
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Hum, looking more closely, in the importPreambuleFromWkb()/importPreambuleOfCollectionFromWkb() cases (introduced when dealing with curve geometries in 2.0), I think that using the existing codes should be possible. OGRERR_NONE could be used to mean "continue processing". No need for -1. So the ret >= 0 could be transformed to ret != OGRERR_NONE
In the importPreambuleFromWkt() case it is more tricky, since we really need to distinguish OK go on, from OK no more processing needed (case of POINT EMPTY, LINESTRING EMPTY, etc...). Perhaps an extra parameter for that would be better.