| Age | Commit message (Collapse) | Author |
|---|
|
|
|
#1198)
|
|
We store the PJ_CONTEXT* in the PJ_OBJ objects, but this
might cause issues in multi-threaded uses.
For example, before this change, let's imagie:
- a PJ_OBJ is created in thread A with a PJ_CONTEXT that
is specific to this thread A
- PJ_OBJ is transfered to another thread that operates on
it. It might thus use the PJ_CONTEXT that was TLS(A)
- in the meantime thread A does completely different things,
but still operate on its PJ_CONTEXT. We might get a
concurrent use of the PJ_CONTEXT despite working on
different PJ_OBJ
Another situation is when using constructor functions that
take two PJ_OBJ. Up to now, we arbitrarily selected the context
of one of the arguments to attach it to the new object.
So better be explicit on which context is used.
For reference, in those wrappers of the C++ API, the
context is mostly used for two things:
- reporting C++ exceptions as PROJ errors with the error handler
attached to the PJ_CONTEXT
- using the database handle that is associated with the PJ_CONTEXT.
|
|
the data/epsg and data/IGNF files
|
|
With projects.h not being available to outside users anymore we need to
define PJ_UNITS, PJ_ELLPS, PJ_PRIME_MERIDIANS and PJ_OPERATIONS
elsewhere.
Related pj_get_*_ref() functions have been removed in favour
of their proj_ namespaced counterparts.
char pointers have been changed to const char pointers.
Resolves #983
Resolved #1147
Make char pointers const
|
|
|
|
We are relying more and more on C99 math functions. On C89 systems where
those functions are not available our own custom versions of those
functions are used instead. So far these has been spread across the code
base. This commit gathers them in the same file and introduces the
proj_math.h header. The build system checks for C99 math functions. If
not found the proj_math.h header make sure that C99 functions are
defined as their pj_ equivalent.
Ideally proj_math.h is included instead of math.h. This removes the need
for any checks against HAVE_C99_MATH in the code making it easier to
read.
For this commit the functions hypot, log1p and asinh has been taken care
of.
|
|
Bare literals are hard to follow and inconsisten with the rest of proj.
|
|
Remove final \n from pj_log messages.
|
|
|
|
There was a mix of pj_log calls with and without a trailing newline.
pj_stderr_logger already adds a newline to the end of each msg, so
pj_log calls don't need their own.
|
|
|
|
null pointer dereference
|
|
Remove 'pj_' prefix from static functions
|
|
Original mispelled constant kept for backward compatibility.
|
|
Functions should only be prefixed with 'pj_' when they can be used in
other parts of the code base and not just within a single file.
Takes care of the last step in #675.
|
|
* Avoid using angle brackets for PROJ headers.
Switching from #include <proj.h> to #include "proj.h",
and correspondingly for projects.h and proj_api.h,
reduces the risk of accidentally picking up a system
installed older version of the header while building
a new version of PROJ.
* Also handle geodesic.h
|
|
Reset error type PJD_ERR_MAJOR_AXIS_NOT_GIVEN for operations
that do not need an ellipsoid.
|
|
|
|
|
|
|
|
|
|
|
|
Parameters such as towgs84, nadgrids and geoidgrids was previously only
handled by pj_transform(). This commit add a compatibility layer in
proj_create() by calling the pj_cs2cs_emulation_setup() function. This
function sets up a handful of predefined transformation objects on the
PJ object that is being created. Each of these transformation objects
are related to the cs2cs-style parameters we are trying to emulate in
the 4D API. That is, if the +towgs84 parameters is used we create
P->helmert with the parameters specified in +towgs84. Similarly for
+axis, +nadgrids and +geoidgrids. When these transformation objects
exists we use them in the prepare and finalize functions in pj_fwd/
pj_inv. If no cs2cs-style parametes are specified we skip those
parts of the prepare and finalizing steps.
Co-authored-by:Thomas Knudsen <thokn@sdfe.dk>
Co-authored-by:Kristian Evers <kristianevers@gmail.com>
|
|
|
|
|
|
|
|
|
|
Previously, when expanding init=foo.bar calls, pj_chomp was first called after collecting all lines, effectively discarding everything after the start of the first comment
|
|
* Some corrections in response to a review by Kristian Evers
|
|
Having non-const variables of static lifetime or even global scope is
usually a bad idea. These variables are inherently constants, and this
should be enforced.
This required marking some functions as not modifying input parameters
and marking some pointers as pointers to const.
One advantage is that the compiler usually puts const static variables
in a read-only code segment, so they can't be modified physically.
This can be verified with `nm` (on POSIX systems).
To avoid changes to the public API, functions returning non-const
pointers to data tables were left intact, but the returned data may not
be modified. Internally we prefer using the proj_list_* functions over
the pj_get_*_ref functions, because the former return const pointers.
|
|
* 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
|
|
* gie support for builtin errcodes, and other improvements
* allow lower case error constants
|
|
Improve error messaging for cct and gie, and do some clean ups in the ellipsoid handling - partially to squash bugs, partially to improve naming consistency which, in turn, improves the readability of the ellipsoid handling code.
Renamed functions:
pj_inherit_ellipsoid_defs has been renamed pj_inherit_ellipsoid_def, while pj_calc_ellps_params has been renamed pj_calc_ellipsoid_params.
The code in get_opt (part of pj_init.c), which handles whether or not an ellipsoid definition should be dragged in from proj_def.dat, has been rewritten. I suspect this was buggy beforehand, and at least the new code is easier to follow (although it may be slightly slower, which is not really a problem as it sits in the setup code, and hence is executed only once).
|
|
|
|
* 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.
|
|
* Introduce geodetic-geocentric conversions, as PJ_xxx style conversion step and as API entry points
* minor improvements and minor bug squashing
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3573 , https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3643 and https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3641 . Credit to OSS Fuzz
|
|
of special cases to handle in pj_init.c
|
|
Allow nested pipelines when wrapped in +init's.
The previous behaviour was to quit pipeline initialization when
encountering a nested pipeline definition. With this commit that
behaviour is changed so that it is possible to nest pipelines as
long as they are defined elsewhere in a init-file.
This is useful in init-files where steps in complicated transformations
can be grouped in "sub-pipelines". These "sub-pipelines" can then be
used as individual steps in a larger and more complicated pipeline.
Nested pipelines are governed by the following rules:
1. You can't have more than one literal +proj=pipeline in a proj-string
2. Pipelines can be nested if they are wrapped up in a +init
3. More than one +init is disallowed in non-pipeline proj-strings
4. +inits are expanded as late as possible, that is they will only be
expanded in single operations (that can be a part of a pipeline)
|
|
* Prevent crashes and leaks on allocation failure
Memory allocation can fail. We need to gracefully handle this case and
prevent dereferencing null pointers.
* Make NULL checks consistent within a file
* Properly report allocation errors
* Improve cleanup in pj_gc_reader.c
* Implement pj_strdup and use instead of strdup
The function strdup is not part of ANSI C 89, but a POSIX extension.
Therefore we can not rely on it being available on all platforms.
|
|
it gives consistent results, and is more safe than the original hack of setting es=0
|
|
In most cases memory deallocation is completely removed from the
code since it can be handled by the default destructor. In a few
special cases a local destructor overrides the default destructor
and makes sure that locally allocated memored is cleaned up correctly.
Move all deallocation from pj_free to pj_default_destructor
Rename pj_latlong.c to fit with the conventional format PJ_latlong.c - freeup was missed here due to wrong naming
Clean up pj_init to avoid double deallocation; Also resolve #576 by adding z_0 and t_0 options in pj_init, while cleaning
Add a prototype for dealloc_params
Added missing errno.h include in pj_ctx.c
Temporarily removing ob_tran from testvarious, to be sure that is where the trouble is
Make PJ_ob_tran.c use proper initialization for the chained projection
proj=ob_tran: make it clear, that we disallow ellipsoidal projections, and, for improved backwards compatibility, turns off default settings, which could inject unwanted ellipsoid definitions
... then also remove the ellipsoid definition from the testvarious test case - which is probably buggy anyway
Work around cs2cs spherical init bug in testvarious; Forbid defs for ob_tran in pj_init
|
|
|
|
* Adding info functions to proj.h API.
Four new functions are added with this commit: proj_info(), proj_pj_info(),
proj_grid_info() and proj_init_info(). Additionally four new data types are
added: PJ_INFO, PJ_PROJ_INFO, PJ_GRID_INFO and PJ_INIT_INFO. The functions
return the corresponding data types.
These functions allows users of the PROJ.4 library to get information about
various PROJ.4 entities and the library itself. The new data types are structs
that contain specific information about either the library instance, a PJ
instance, a grid or an init file. Together the four new functions cover a big
part of the functionality in the semi-public projects.h API and should hopefully
make it easier for user to migrate their code to the proj.h API in the future.
Besides covering already existing functionality in the old API, this commit
introduces the ability to add metadata to init-files. This is primarily added
to give users a way of knowing which version of the EPSG database they are
using, but it also comes in handy for other init-files. The init-file metadata
is added directly to the init-file as a special "projection" called "metadata".
The info projection of the epsg init-file is thus described as:
<metadata> +version=9.0.0 +origin=EPSG +lastupdate=2017-01-10
The proj_init_info() function uses the internal pj_param() to read the
metadata. As a consequence, "metadata" will not be available as a the name of
a projection in the future. This is a reasonable price to pay considering the
ease of the implementation of adding metadata to init-files this way, and of
course that "metadata" is a very unlikely name for a projection in any case.
A metadata tag has been added to all init-files in the nad-directory. For most
only a subset of the possible parameters has been added.
* Replaced calls to sprintf and strncpy with safer options. Added pj_strlcpy for internal use.
* Fail gracefully when getting non-initialized PJ in proj_pj_info()
* Change length of filename member in PJ_INIT_INFO and PJ_GRID_INFO to 260 (MAX_PATH)
|
|
With the introduction of transformation pipelines it is now a valid
use case to have more than one +init argument in a proj string. This
commit makes sure that all +init's are expanded.
Added test case to PJ_pipeline.c for use of multiple +init's in a
proj-string.
Fixes #479.
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2000. Credit to OSS Fuzz
|
|
* pj_transform() crashes on a catalog that has no matching grid
* pj_free() and pj_gc_unloadall() badly interact. No longer try to free the
catalog object in pj_free(). That is the job of pj_gc_unloadall()
* Fix memory leaks in pj_gc_readcatalog() and pj_gc_unloadall()
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1923
Credit to OSS Fuzz.
|
|
Can happen when any of the src/dest projection has a +catalog parameter.
Fix a memory leak on catalog_name as well.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1799
Credit to OSS Fuzz
|
|
|
