If polygon edges are almost coincident, or when there is an extremely
small overlap between polygons, GPC may in very rare cases suffer from
numerical accuracy issues, resulting in exceptions such as Access
Violation or Segmentation Fault. There is no code fix for this
condition at present. However, the issue can usually be avoided if all
vertex positions are snapped to a grid before processing by gpc (at a
grid resolution suitable for your application). A grid-size with a
binary power works best - for example a grid spacing
G of

G = pow(2.0,-25.0)

but a decimal size can also work. So all x and y components of your
vertices should be adjusted with code something like:

x = (round(x / G) ) * G

An alternative approach is to experiment with different values of GPC_EPSILON, the internal constant GPC uses to decide if two
foating-point values are "the same", such as when comparing
displacements or angles. Its default value is DBL_EPSILON, which is
defined in <float.h> as "the difference between 1.0 and the smallest
double bigger than 1.0, which is typically a number like
2.2204460492503131e-16".

Can GPC be adapted to compute clipping or intersection between a
polygon and a line segment?

There is no simple way of adapting GPC to handle polygon and line
segment clipping, since its core algorithm is based around classifying
regions of the 2D plane as being inside or outside the clip and
subject polygons, and generating a polygon on the perimeter of the
required combination of these regions. The approach does not fit well
with dealing with line segments.

Why has GPC removed some of my polygon's vertices?

GPC's clipping algorithm removes any redundant vertices on horizontal
edges (but only on horizonal edges). This can sometimes result in
unexpected results. A workaround is to apply a rotation to the
polygons, clip, and then reverse the rotation.