Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential bug in CS::add() #997

Closed
pramsey opened this issue Nov 20, 2023 · 1 comment · Fixed by #999
Closed

Potential bug in CS::add() #997

pramsey opened this issue Nov 20, 2023 · 1 comment · Fixed by #999
Labels

Comments

@pramsey
Copy link
Member

pramsey commented Nov 20, 2023

This line

if (cs.stride() == stride() && cs.hasM() == cs.hasM()) {

Seems mighty suspicious, testing cs.hasM() == cs.hasM() ... @mwtoews or @dbaston can you look?

@dbaston
Copy link
Member

dbaston commented Nov 20, 2023

Definitely incorrect although it would only cause an error with an unpadded XYM sequence which GEOS does not currently use:

// If GEOS_COORDSEQ_PADZ is defined:
// - XY sequences will be stored as XYZ
// - XYM sequences will be stored as XYZM
// This prevents incorrect results when an XYZ Coordinate is read from
// a sequence storing XY or XYM. When GEOS is changed to check
// coordinate types throughout the libary, this can be undefined to
// store coordinates efficiently.
#define GEOS_COORDSEQ_PADZ

@dbaston dbaston added the Bug label Nov 20, 2023
dbaston added a commit to dbaston/libgeos that referenced this issue Nov 21, 2023
Logic error only causes an incorrect result when GEOS_COORDSEQ_PADZ is
not defined.

Fixes libgeos#997
dbaston added a commit that referenced this issue Nov 21, 2023
)

Logic error only causes an incorrect result when GEOS_COORDSEQ_PADZ is
not defined.

Fixes #997
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants