Magnus Jacobsson [Tue, 19 Oct 2021 05:15:02 +0000 (07:15 +0200)]
sfio: correct misleading indentation in SFnputc macro definition
Fixes errors like this when building with CMake (which uses -Wall,
-Wextra and -Werror) on Ubuntu 21.10 with gcc 11.2.0.
../lib/sfio/sfvprintf.c:76:13: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
76 | if(n != w) goto done; n = 0;\
| ^~
../lib/sfio/sfvprintf.c:511:25: note: in expansion of macro ‘SFnputc’
511 | SFnputc(f, '0', n);
| ^~~~~~~
../lib/sfio/sfvprintf.c:511:41: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
511 | SFnputc(f, '0', n);
| ^
../lib/sfio/sfvprintf.c:76:35: note: in definition of macro ‘SFnputc’
76 | if(n != w) goto done; n = 0;\
| ^
Magnus Jacobsson [Tue, 19 Oct 2021 05:15:02 +0000 (07:15 +0200)]
sfio: correct misleading indentation in REINIT macro definition
Fixes errors like this when building with CMake (which uses -Wall,
-Wextra and -Werror) on Ubuntu 21.10 with gcc 11.2.0.
../lib/sfio/sfdisc.c:114:25: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation]
114 | { for(d = f->disc; d && !d->iof; d = d->disc) ; \
| ^~~
../lib/sfio/sfdisc.c:119:9: note: in expansion of macro ‘REINIT’
119 | REINIT(oreadf, readf, Sfread_f);
| ^~~~~~
../lib/sfio/sfdisc.c:115:25: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’
115 | if(DISCF(d,iof,type) != oiof) \
| ^~
../lib/sfio/sfdisc.c:119:9: note: in expansion of macro ‘REINIT’
119 | REINIT(oreadf, readf, Sfread_f);
| ^~~~~~
Magnus Jacobsson [Tue, 19 Oct 2021 05:15:02 +0000 (07:15 +0200)]
sfio: correct misleading indentation in GETDISCF macro definition
Fixes errors like this when building with CMake (which uses -Wall,
-Wextra and -Werror) on Ubuntu 21.10 with gcc 11.2.0.
../lib/sfio/sfdisc.c:68:11: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation]
68 | { for(d = f->disc; d && !d->iof; d = d->disc) ; \
| ^~~
../lib/sfio/sfdisc.c:71:5: note: in expansion of macro ‘GETDISCF’
71 | GETDISCF(oreadf, readf, Sfread_f);
| ^~~~~~~~
../lib/sfio/sfdisc.c:71:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’
71 | GETDISCF(oreadf, readf, Sfread_f);
| ^~~~~~
../lib/sfio/sfdisc.c:69:11: note: in definition of macro ‘GETDISCF’
69 | func = d ? d->iof : NULL; \
| ^~~~
lib/glcomp: replace header guards with more modern #pragma once
Amusingly it looks like some time in the past (prior to version control) someone
got a little trigger happy find-and-replacing “CompText” with “CompFont”.
CMake: only pass 'YY_NO_UNISTD_H' to Flex when unistd.h is not found
This macro tells Flex that #including unistd.h should be avoided. There is no
need for this on almost any platform except Windows, hence why `YY_NO_UNISTD_H`
is only mentioned elsewhere in the MS Build build system, not in the Autotools
build system. In the CMake build system which is meant to be used across Windows
and non-Windows platforms, we can do something more nuanced and depend on the
existence check of unistd.h itself.
extokens: fix missing NUL terminator append in GVPR tokenization
This is the second half of a bug fix following the prior commit.
Commit 971293551421455a0d939b9f8cea17356b7968f8 refactored this code to avoid
the use of an SFIO buffer, inadvertently introducing a bug. The change did not
account for the source buffer not being NUL terminated. This fix wicks closer to
the original code, not assuming a NUL terminator and copying a known number of
bytes into the destination.
exsplit: fix missing NUL terminator append in GVPR splitting
Commit 7ef9d53e2e6dc53c44939ace7a9cad57c3aa00bf refactored this code to avoid
the use of an SFIO buffer, inadvertently introducing a bug. The change did not
account for the source buffer not being NUL terminated. This fix wicks closer to
the original code, not assuming a NUL terminator and copying a known number of
bytes into the destination.
Match function signature in definition with declaration
GCC11 throws the following warning:
graphviz/lib/pathplan/shortest.c:93:47: warning: argument 2 of type ‘Ppoint_t *’ {aka ‘struct Pxy_t *’} declared as a pointer [-Warray-parameter=]
93 | int Pshortestpath(Ppoly_t * polyp, Ppoint_t * eps, Ppolyline_t * output)
| ~~~~~~~~~~~^~~
In file included from graphviz/lib/pathplan/pathutil.h:15,
from graphviz/lib/pathplan/shortest.c:16:
graphviz/lib/pathplan/pathplan.h:22:59: note: previously declared as an array ‘Ppoint_t[2]’ {aka ‘struct Pxy_t[2]’}
22 | extern int Pshortestpath(Ppoly_t * boundary, Ppoint_t endpoints[2],
| ~~~~~~~~~^~~~~~~~~~~~
[2/20] Building C object lib/pathplan/CMakeFiles/pathplan.dir/route.c.o
graphviz/lib/pathplan/route.c:76:29: warning: argument 4 of type ‘Ppoint_t *’ {aka ‘struct Pxy_t *’} declared as a pointer [-Warray-parameter=]
76 | Ppoint_t * evs, Ppolyline_t * output)
| ~~~~~~~~~~~^~~
In file included from graphviz/lib/pathplan/pathutil.h:15,
from graphviz/lib/pathplan/route.c:17:
graphviz/lib/pathplan/pathplan.h:28:39: note: previously declared as an array ‘Pvector_t[2]’ {aka ‘struct Pxy_t[2]’}
28 | Pvector_t endpoint_slopes[2],
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~
The problem of “call `qsort` but also access some external context” is still
relevant, but this functionality has been standardized into `qsort_s` in C11,
not `qsort_r`.
exerror/exwarn: allow GNU-compatible compilers to detect misuse
This lets compilers like GCC and Clang notice when these functions are called
with a format string that is inconsistent with the remaining arguments and issue
a warning. This detects problems like those fixed in the prior commit.
The `ps_txt` array is only used in calls to `cat_libfile`, which does not need a
single line per array entry. By fusing all strings into the first `ps_txt` array
entry, we can reduce the number of eventual `gvputs` calls, accelerating the
entire operation.
Magnus Jacobsson [Sun, 10 Oct 2021 10:05:20 +0000 (12:05 +0200)]
CI: move generation of COLLECTION from macOS build template to individual jobs
This is no functional change, but makes the macOS build jobs more
similar to the Linux build jobs and opens up for letting the macOS
CMake and autotools builds use different COLLECTION in the future.
Magnus Jacobsson [Sun, 10 Oct 2021 09:06:31 +0000 (11:06 +0200)]
CI: don't generate GRAPHVIZ_VERSION file in macOS CMake build job
The version is generated internally to a variable in the CMake build
job and the downstream test job generates the file itself since commit fea17b6a9738eb96f037e22538d1885a75f20698.
This commit moves the generation of the GRAPHVIZ_VERSION file from the
build template to the macOS autotools build job.
remove generation of ps.h and commit generated output instead
The generation of ps.h from ps.txt was trivial and ps.txt was no easier to edit
or update than the resulting generated header. Removing it and using a static
source instead accelerates all three builds, increases portability and moves
towards dropping the dependency on Awk.
projects / graphviz / log