| Age | Commit message (Collapse) | Author |
|---|
|
torad_coord() of gie.c has this sequence:
```
if( cond )
axis = l->param + strlen ("axis=");
n = strlen (axis);
```
When the if branch is evaluated, n is always zero
even if on inspection axis is non empty
The reason is that the struct ARG_list which is the
type of l use a variable-length array for the param member
struct ARG_list {
paralist *next;
char used;
char param[1];
};
But this is not a proper way of declaring it, and
gcc 8 has apparently optimizations to detect that l->param + 5
points out of the array, hence it optimizes strlen() to 0.
Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914
According to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html,
the proper way of declaring such arrays is to use [0]
|
|
|
|
null pointer dereference
|
|
|
|
In cases such as:
proj=pipeline step proj=utm zone=32 ellps=GRS80 ...
The pj_init code would pick up the ellps information (and other material such as false eastings and northings) from the utm step and place it into the PJ object of the pipeline driver.
This is not the intention, and is eliminated in this PR by terminating parameter searching (done by pj_param) once a step parameter is reached.
|
|
* Free format now in cmd lines, in gie, and in init files
* Corrected handling of defaults
* Add demo of integrated definition and validation
* Repair stack-smashing memmove in get_init
* repair paralist corruption, clean up debug output
* Install test files for nmake builds
* Add many improvements following suggestions by @schwehr
* Be consistent in requiring lower case everywhere in gie.c
Also, this Fixes #703 and Fixes #697
|
|
* Replace pj_ell_set with reimplementation supporting ellipsoid inheritance
* remove unreachable code from pj_ell_set.c
* Swap steps, so ellps args are read first, in accordance with historical behaviour
* Add ellipsoid tests to CI targets
* Reduce some optimistic tolerances
OS/X appears to have a slightly off float handling, resulting in differences at the nanometer level. Switching to 10 nm.
|
|
|
|
Introducing the Horner polynomial evaluator also introduces the need for
very long +init:tag arguments (a n'th order 2D polynomium has
(n+1)(n+2)/2 coefficients, and n is typically in the range 5-10, i.e. up
to around 60 coefficients for each polynomium, and there are 4 polynomia
in a complete back/forward transformation set).
Hence, in this commit, along with the first part of the Horner code, the
code for reading +init files has been modified in a (for all practical
purposes) backwards compatible way, by making it possible to introduce
line continuations by escaping line breaks, i.e. preceding them with a
backslash.
An escaped line break works (as it would in TeX), by skipping all
following whitespace, including interspersed #-comments. This simple
extension makes it possible to create very long initialization elements
without losing track of the structure (cf. s45b.pol and pj_init_test.c
in the examples-directory for a demo).
The s45b.pol file was created by hand-editing the output of the software
doing the original constrained adjustment for the polynomial
coefficients. The simple adding of the “skip following whitespace and
comments” feature has made it possible to retain almost all metadata
from the source material.
This is considered very important, since 1) For the lack of a prior
common file format for geodetic polynomial coefficients, there is a good
chance that this will become THE standard, at least for the time being,
and 2) Without the metadata represented, it will be very hard for a
human to debug code involving a slightly misrepresented polynomium.
Due to the current architecture of the pj_init.c code (mostly around the
fill_buffer() function), it is next to impossible to implement the line
continuation functionality in full generality. Hence, it has been
necessary to limit this format extension to files smaller than 64 kB.
* Correction of spherical HEALpix test case
The first HEALpix test case in nad/testvarious is clearly intended to
invoke the spherical form of HEALpix.
It does, however, specify the spheroid using the +a=1 size parameter,
without specifying any shape parameter.
But since +no_defs is not specified either, a shape parameter is picked
up from the nad/proj_def.dat file (where ellps=WGS84 is given in the
<general> section).
It appears that this has not happened before I updated the pj_init code to support projection
pipelines (see below). I do, however, believe that the present behaviour is the correct one,
and rather than retrohacking the pj_init code, to (incorrectly, I
believe) reproduce the prior behaviour, I have corrected the test case
invocation in nad/testvarious to specify the spheroid using the +R=1
size parameter (which was already used in the following test case).
* Repair scaling of projections stomping on value of semimajor axis
* Workaround MSVC HUGE_VAL misimplementation.
The "return const err object" idiom (i.e. const <type> err =
{HUGE_VAL,...}; ... if (bad) return err) is problematic to implement
due to MSVC's misimplementation of HUGE_VAL as a non-const.
Hence, we need to run-time initialize these. In the pj_inv functions,
this was mistakenly done to the wrong object.
For pj_fwdobs/invobs and the remaining part of the obs-based API, this
is now worked around by providing functions returning a run time
HUGE_VAL initialized PJ_OBS or PJ_COO resp.
Obnoxious, but given MSVC's market penetration there is really not much
else we can do.
|
|
|
|
Remove setlocale() use in pj_init_ctx(), and replace uses of atof() &
strtod() by their locale safe variants pj_atof() and pj_strtod().
Proj versions from now advertize #define PJ_LOCALE_SAFE 1 in proj_api.h
and export pj_atof() & pj_strtod()
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1856 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1839 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1827 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1515 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1025 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@854 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@776 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
