lefty SFgetHomeDirs: standardize 'qsort' usage

The `qsort` function has been ISO standardized as far back as C89. There is no
need for workaround on any toolchain that correctly implements C99.

lefty: remove unnecessary getwd prototype

The only use of this function was removed in
a4468a2a875dadaee313fb2a7333881cee85fb91.

Merge branch 'smattr/0824fd6b-4a2f-49f4-99cc-ed8100eecba5' into 'main'

yet more warning squashing

See merge request graphviz/graphviz!2166

sparse_stress_subspace_majorization_kD: replace a boolean with a C99 bool

And reflow some text.

stress_majorization_kD_mkernel: replace a boolean with a C99 bool

And reflow some text.

dist_data: replace a boolean with a C99 bool

get_mq: abbreviate a malloc;memzero

The calloc function can do this more concisely and efficiently.

exisAssign: remove unnecessary bracketing

expr lexname: return a 'const char*'

The callers of this do not modify the returned value. This squashes a
-Wcast-qual warning.

expr global: squash -Wunused-parameter warning

expr global: remove unnecessary casts

expr print: use a 'size_t' for iteration

Squashes a -Wsign-compare warning.

expr scan: use a 'size_t' for iteration

Squashes a -Wsign-compare warning.

Merge branch 'smattr/f7c14ca2-789a-46b0-b5f1-2cacd08dfbc5' into 'main'

more warning squashing

See merge request graphviz/graphviz!2158

lu_decompose: remove unnecessary bracketing

lu_decompose: rephrase comparisons against 'biggest' to avoid equals

This squashes some -Wfloat-equal warnings, but has the same effect due to the
surrounding code ensuring `biggest` can only ever increase from 0.

lu_decompose: rephrase an open coded fmax

lu_decompose: remove micro-optimization of avoiding multiplication by 0

This is not on a hot path and 0 multiplications are not costly on modern
processors. This squashes a -Wfloat-equal warning.

find_ints: squash a -Wswitch-default warning

This switch on the result of a call to `gt` only ever results in -1, 1, or 0.
The 0 case was pretty clearly intended to be a no-op here.

neatogen gt: rephrase into something more obvious

This is intended to preserve the same semantics. It not only avoids two
-Wfloat-equal warnings, but makes this code so close to the leading comment that
the comment can simply be removed now.

neatogen gt: rephrase to avoid having to cast pointers to this function

neatogen between: rephrase to avoid -Wfloat-equal warnings

This is intended to have the same semantics.

find_ints: remove unused 'polygon_list' parameter

use a header with prototypes to squash bindings -Wmissing-prototypes warnings

This removes 30 build warnings and is generally a cleaner way of doing this.

Merge branch 'smattr/25F2CD31-80C6-48D6-A6EE-9D7EEEB2FA14' into 'main'

smyrna: remove unused materials.h

See merge request graphviz/graphviz!2160

smyrna: remove unused materials.h

Merge branch 'smattr/FDB29D45-8A65-4119-B80E-24C4F73985C5' into 'main'

more smyrna clean up

See merge request graphviz/graphviz!2161

Merge branch 'windows' into 'main'

Update schema of generated deploy.py JSON

See merge request graphviz/graphviz!2174

Update schema of generated deploy.py JSON

I've updated the schema in the docs dir, to make room for Windows releases in here.

I haven't filled in the windows array yet.

smyrna: remove unused hotkey macros

smyrna: remove unused 'get_key_action'

smyrna: remove unused LOCATION_X macros

smyrna: remove unused tvnode types

smyrna: remove 'attach_camera_widget' prototype

This function is not implemented.

smyrna: remove unused 'countof' macro

smyrna apply_actions: remove useless break statement

smyrna: remove unused 'setGdkColor'

smyrna realize: remove useless trailing return statement

smyrna: remove some commented out prototypes

Merge branch 'smattr/d8544aa0-66a2-485d-bc01-4017f399a188' into 'main'

progress on removing sfio

See merge request graphviz/graphviz!2154

gvpr mkStmts: use internal temporary buffers instead of sfio

This simplifies code, progresses the ongoing sfio removal goal, and also makes
it more obvious to the compiler how to optimize this code.

Related to #1873, #1998.

gvpr mkStmts: make 'lbl' parameter const

The pointed to data is not modified within this function.

gvpr mkBlock: remove an unnecessary use of an sfio buffer

Related to #1873, #1998.

gvpr mkBlock: more precise bounds on internal buffers

On most platforms, `BUFSIZ` is likely large enough to contain the data printed
to it. But since we know the exact data that is placed in these buffers, we can
write this code more portably.

expose itos buffer size as a constant

Elsewhere in Graphviz we sometimes need to print ints into fixed sized buffers,
but not using itos. So it is useful to have a value for the number of bytes this
requires that is also regularly validated by the Graphviz test suite. That is,
uses of this constant should be robust to future environment/platform changes,
because the itos tests will fail, prompting an update of this constant, that
will then correctly affect all usages of this.

gvpr mkBlock: scope a buffer closer to its uses

gvpr compile: make 'lbl' parameter const

The pointed to data is not modified within this function.

gvpr compileProg: remove now unnecessary 'strdup'

Now that the backing memory for `endgsfx` is no longer hosted in a temporary
sfio buffer that may be overwritten, there is no need to duplicate this further.

gvpr doFlags: rewrite to avoid dynamic memory allocation

There is no need for this function to go through the overhead of sfio and
dynamic string construction just for this simple logic.

Related to #1873, #1998.

gvpr compileProg: remove some dead code

The `doFlags` function, at a minimum, prints "\n" into its buffer so there is
never a case when the result is an empty string.

remove unused 'ptchk' function

gvpr compile: make 'sfx' parameter const

The pointed to data is not modified within this function.

Merge branch 'smattr/0d085d9e-4d11-43b3-9d0c-d940e49e10d5' into 'main'

rewrite `INT2PTR` and `PTR2INT` as functions

See merge request graphviz/graphviz!2153

 lib/gvpr/compile.c: rewrite 'PTR2INT' macro as a function

This is more straightforward, type safe, and shorter. This also squashes 13
-Wbad-function-cast compiler warnings.

lib/gvpr/compile.c: rewrite 'INT2PTR' macro as a function

This is more straightforward, type safe, and shorter.

Merge branch 'smattr/1c348b36-65e2-4302-b77e-2c0e358a9066' into 'main'

squash some -Wmissing-field-initializer warnings

See merge request graphviz/graphviz!2152

p_doubleoctagon: squash a -Wmissing-field-initializer warning

p_invhouse: squash a -Wmissing-field-initializer warning

p_invtrapezium: squash a -Wmissing-field-initializer warning

p_invtriangle: squash a -Wmissing-field-initializer warning

p_doublecircle: squash a -Wmissing-field-initializer warning

p_cylinder: squash -Wmissing-field-initializer warning

p_underline: squash a -Wmissing-field-initializer warning

p_component: squash -Wmissing-field-initializer warning

p_box3d: squash a -Wmissing-field-initializer warning

p_folder: squash a -Wmissing-field-initializer warning

Merge branch 'smattr/f144d6f4-ad9a-4600-815b-d8a29575145d' into 'main'

teach the Autotools build system that PHP headers are not part of Graphviz

See merge request graphviz/graphviz!2155

teach the Autotools build system that PHP headers are not part of Graphviz

tl;dr: this removes 166 spurious compiler warnings.

When building the Graphviz PHP bindings, PHP headers are included and the build
system was treating these as local includes; things to be warned about. With PHP
7, this was generating a *lot* of warnings. Many of these issues are already
fixed upstream in PHP but, moreover, these files are not part of Graphviz and
warnings about them should not be part of the Graphviz build.

This commit teaches the compiler that the PHP headers are system headers, not
local headers, and warnings about them should be suppressed.

Some open questions:

  1. I explored finding an alternative `--includes` option to `php-config` that
     would give `-isystem` prefixed paths instead of `-I` prefixed paths. It
     would be cleaner than this commit to do such a thing in configure.ac, but
     such an option does not appear to exist.

  2. Vim highlights the use of `$(patsubst …)` as if it is an error. Is it
     illegal to use GNU Make functions in Makefile.am files? I do not think so,
     but given how long both Autotools and Vim have co-existed for, I am
     wondering if this highlighting is deliberate and telling me something I am
     missing.

Merge branch 'improve-cygwin-cmake-build' into 'main'

Improve crlf handling in windows-cygwin-cmake-build CI job

See merge request graphviz/graphviz!2165

CI: remove obsolete exporting of SHELLOPTS = "igncr" in windows-cygwin-cmake-build

This is no longer necessary since crlf is now replaced with lf in all
text files in the repository before Cygwin starts.

Exporting SHELLOPTS has the negative side effect that other flags such
as -e, -u and -x are inherited by child processes which could cause
invoked bash scripts to fail (because of -u) and abort (because of -e)
unintentionally. While this does not happen in the current Cygwin
CMake build, this has been observed in Cygwin autotools builds that
will be introduced in an upcoming MR. This commit ensures that this
can not occur in the future for CMake builds either.

The -x option is more or less harmless, but causes excessive logging
in invoked scripts. This can be seen in
e.g. https://gitlab.com/graphviz/graphviz/-/jobs/1593005342.

CI: change crlf to lf in worktree in windows-cygwin-cmake-build

Replace crlf with lf in all text files in the worktree before starting
Cygwin.

This will allow an upcoming commit to stop exporting SHELLOPTS =
"igncr" which has some negative side effects explained in that commit.

CI: correct name of version file to archive in windows-cygwin-cmake-build job

The name was changed in c188de232323285caabb7f96c5822dec2db99645 was
missed when https://gitlab.com/graphviz/graphviz/-/merge_requests/2137
was rebased.

ci/build.sh: CMake: use pushd and popd instead of cd

Merge branch 'smattr/4878700D-5019-4BF2-B61B-60F2AB2DF3E7' into 'main'

fix some of Stephen's posted warnings

See merge request graphviz/graphviz!2151

smyrna update_columns: fix incorrect call to initGrid

Thanks to backwards compatibility with K&R C, a function declared with no
parameter list takes an unspecified number of parameters. So it is legal to call
such a function with any arguments. Nevertheless on macOS Clang notices:

  tvnodes.c:354:18: warning: too many arguments in call to 'initGrid'

as noted by Stephen.¹ This commit both fixes the call and alters `initGrid` to
have a more strict signature. This appears to be the correct fix to me as `str`
is duped into `g->flds` below this which is what I think the mistaken call to
`initGrid` believed was happening inside `initGrid`.

¹ https://forum.graphviz.org/t/tracking-down-warnings-old-news-to-some-of-you/821

smyrna renderSelectedNodes: fix no-op loop

This condition was pretty clearly meant to guard the `continue`, not nothing. On
macOS, Clang dutifully warns:

  topviewfuncs.c:276:21: warning: if statement has empty body [-Wempty-body]

as noted by Stephen.¹

¹ https://forum.graphviz.org/t/tracking-down-warnings-old-news-to-some-of-you/821

smyrna object_color: rephrase to make initialization of 'vis' more obvious

Auditing all call sites of this function reveals it is only ever called with
edges and nodes. But the compiler could not see enough to know this. On macOS,
Clang dutifully warns:

  topviewfuncs.c:165:13: warning: variable 'vis' is used uninitialized whenever
    'if' condition is false [-Wsometimes-uninitialized]

as noted by Stephen.¹

¹ https://forum.graphviz.org/t/tracking-down-warnings-old-news-to-some-of-you/821

lefty: remove unused 'myyylex'

On macOS, Clang correctly warns:

  dotlex.c:50:20: warning: all paths through this function will call itself
    [-Winfinite-recursion]

As noted by Stephen.¹

¹ https://forum.graphviz.org/t/tracking-down-warnings-old-news-to-some-of-you/821

gv2gml: use C99 support to portably print uint64_t variables

This squashes a number of -Wformat compiler warnings, as reported by Stephen.¹

¹ https://forum.graphviz.org/t/tracking-down-warnings-old-news-to-some-of-you/821

Merge branch 'smattr/40cab147-e739-4c48-8774-ed75ce2dc89a' into 'main'

some neatogen clean up

See merge request graphviz/graphviz!2150

ELleftbnd: remove unnecessary for loop condition

An empty condition is the same as true/1.

lib/neatogen/hedges.c: abbreviate increment, decrement

right_of: use a C99 bool for 'right_of_site' for clarity

hintersect: use a C99 bool for 'right_of_site' for clarity

hintersect: reflow some text

right_of: remove unnecessary bitwise operations

This code was using bitwise operations to substitute for logical boolean
operators. This is sometimes justified, to avoid the short-circuit behavior of
the logical operators that can impair CPU pre-fetching/speculation. However, in
this situation this code is not on a hot path and the bitwise operators were
just making this code harder to read.

lib/neatogen/hedges.c: remove unnecessary bracketing

lib/neatogen/hedges.c: remove unnecessary casts

remove unnecessary casts of 'getfree' return value

fdpAdjust: remove some unnecessary bracketing

fdpAdjust: reflow some text

rePos: abbreviate some scaling

newpos: abbreviate some accumulation

areaOf: reflow some text

countOverlap: reflow some text

geomUpdate: rephrase and condense some open coded fmax/fmin

scomp: remove unnecessary brackets

chkBoundBox: rephrase and condense some open coded fmax/fmin

Merge branch 'smattr/210FD7B7-14C5-437F-BD2D-064D7A0B0026' into 'main'

fix: do not overwrite exparse.h during MSBuild compilation

See merge request graphviz/graphviz!2163

fix: do not overwrite exparse.h during MSBuild compilation

Commit 09973560cc67c5277df8732ebba75da784afbe51 altered exparse.h to be a static
checked-in file instead of generated by Bison. This passed CI testing, but
unfortunately it was not noticed that on Windows MSBuild this resulted in the
build process still generating exparse.h and overwriting the in-repo copy.

This change reverts the Bison command used during MSBuild to generate the
default y.tab.c/y.tab.h output, more closely aligning it with the other build
systems.