This seems to have been broken since CMake support for lib/topfish was
introduced in 45893ca105777e1c5b97788cd169e400250ffa1f. But it was never noticed
because there is no executable in the CMake build system that links against
topfish yet.
Note that the target here is named “edgepaintib” in anticipation of future
enabling of cmd/edgepaint claiming the name “edgepaint”. This also does not
define a separate liblab_gamut, as the Autotools build does. This separate
library seems only useful for cmd/edgepaint, so it does not seem worth splitting
it out as a separate library.
This seems to have been a mistake in aadee957012e676c9aaf36ec40cb2860c178e269.
lib/edgepaint does not depend on libANN, so it does not seem correct to apply
ANN’s CFLAGS when compiling it.
CI: move macOS dependency installation out of line
Makes these a little easier to manage. Note that this also unifies the runtime
dependencies installed in Autotools and CMake jobs which simplifies ongoing
maintenance.
This is the equivalent of b4925c87f1e28a1bc66d111ef046e4e083db8c5b and friends,
but for mingle. It was not previously detected that this problem also affects
mingle because it is not currently built on macOS or Windows in CI. This will be
improved in future.
htmlparse.y: consistently treat 'kind' as a 'char'
The `kind` field in `htmllabel_t` is a `char`, so this code was causing
conversion compiler warnings when trying to assign an `int` to it. We can avoid
this ambiguity by consistently using the same type everywhere.
Nothing in the build systems defines this macro. It is also unclear how this
code could be used given it calls `pathnext`, a function that has never been
committted to the Graphviz repository.
This function was only ever called with `0` as `flags`, which disables a lot of
its logic. We can reduce the amount of ongoing code to maintain by paring this
back to just the core in use.
This change replicates and extends the exit-on-failure allocation wrappers from
lib/common/memory.c into a header-only implementation in cgraph. The existing
common wrappers worked but there were two limitations preventing their wider
use:
1. lib/common is not the base of the Graphviz dependency graph. E.g.
lib/cgraph does not depend on lib/common, preventing calling
lib/common/memory.h functions from cgraph code. lib/cgraph is not the base
of the dependency graph either (it depends on lib/cdt), but it has become a
de facto home for header-only implementations of general utility functions
called throughout the rest of the Graphviz code base.
2. lib/common is not linked against by every Graphviz component. This meant
other code could attempt to call functions in lib/common/memory.h but would
fail to link because it was not pulling in lib/common/memory.c.
Relocating these functions neatly solves both the above two. It also has the
side effect of allowing compilers to inline these short wrappers. This could
(and would) previously be achieved with Link-Time Optimization, but now a
regular optimizing compilation can also achieve this.
Future changes will remove the lib/common/memory.c wrappers in favor of these.
Stephen C North [Mon, 7 Mar 2022 23:39:41 +0000 (18:39 -0500)]
Attempt to fix initialization of subgraph attributes on existing subgraphs…
Attempt to fix initialization of subgraph attributes on existing subgraphs when
a new root graph attribute is created.
Fix issue 2184, initialization of existing subgraph attributes when a new top
level graph attribute is created. Looks ok, but new code unviewsubgraphsattr is
executed on many of the test graphs, so this should be tested carefully.
This function was retaining a pointer to memory pointed to by its parameter,
`name`, in the global `suffix`. So it is unsafe to call this with anything
except a long lived string. We can make this more obvious/explicit by inlining
the use of `outfile`, the only parameter it is ever called with.
GD plugin: remove repurposing of 'tell' member of I/O context
The GD plugin was using (abusing) the `gdIOCtx.tell` field as a way to pass
around the Graphviz context through GD library functions and callbacks. The GD
docs¹ have this to say about the `tell` field:
The seek and tell functions are only required in conjunction with the gd2 file
format, which supports quick loading of partial images.
The Graphviz GD plugin _is_ using gd2 functionality, so it seems its usage only
works out because it coincidentally does not hit any code paths that use `tell`.
We can avoid this latent issue entirely by rephrasing the way the plugin passes
the Graphviz context around to something less brittle. The approach taken in
this commit is inspired by something like Linux’s `container_of` macro.
The GD plugin was creating `gdIOCtx` objects on the stack with some
uninitialized members. At time of writing, the GD docs¹ claim this struct’s
layout is:
typedef struct gdIOCtx
{
int (*getC)(gdIOCtxPtr);
int (*getBuf)(gdIOCtxPtr, void *, int wanted);
void (*putC)(gdIOCtxPtr, int);
int (*putBuf)(gdIOCtxPtr, const void *, int wanted);
// seek must return 1 on SUCCESS, 0 on FAILURE. Unlike fseek!
int (*seek)(gdIOCtxPtr, const int);
long (*tell)(gdIOCtxPtr);
void (*gd_free)(gdIOCtxPtr);
} gdIOCtx;
So Graphviz’ usage was leaving `getC`, `getBuf`, `seek`, and `gd_free`
uninitialized. This seems to work out OK; Graphviz’ usage of libgd apparently
does not involve any code paths that use these members. But this does not seem
to be an API guarantee. This change zeroes these members for future stability.
projects / graphviz / log