Open sckott opened 5 years ago
any ideas @hollist @mpadge ?
I'll have a look...
Hmmm... I'm not really sure how the src code works here. Two things that appear potentially unsafe:
nH = strCoord.find_first_not_of(" \t", 0);
- unable to tell (without me delving deeper) if the first non-space will always denote sign? Could there be breaking use cases here?The unsafe type conversions in particular ought to be addressed in the interests of "best practice" - have you tried clang++ -Weverything
on it? I imagine that would generate quite a barrage. Happy to help out if ya want - just give a shout!
thaks @mpadge ! I haven't tried clang++ -Weverything
on it yet, will do if you can give me a hint of how to do that 😬
maybe your comments support #6 ? - that is, for re-writing the src side of the pkg perhaps. another motivation is the license - it's unclear to me what changing the code does with respect to the license. it's not a typically used license.
now working with the rewrite on branch src-rewrite
latlong.cpp
need to do special calculation when longitude values greater than 180. perhaps it will require user input to a parameter. if a lon value is 120 it could be in the -180/180 range, or the 0-360 range. if a lon value is 190 then it's invalid in the -180/180 range and valid in the 0-360 range. maybe just a boolean parameter for this
Looked into adjusting the C++ code to support 0-360, but not sure how to make it work exactly.
pretty sure this line https://github.com/ropenscilabs/parzer/blob/master/src/CLongLatString.cpp#L284 is what we need to change, but changing it to e.g.,
CheckRange(dDeg, 0.0, 360.0);
then makes -360 valid, whereas we only want -180 through 360 valid. So seems like it's doing anabs
on the data somewhere but I don't see that happening at leastI guess there's the approach of specifying whether your inputs are -180/180 or 0/360, but that seems not very convenient