dotgen: squash -Wsign-conversion warning in 'doDot'
The compiler says:
dotinit.c: In function 'doDot':
dotinit.c:454:24: warning: conversion to 'unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
454 | pinfo.margin = Pack;
| ^~~~
But from the surrounding code and the implementation of `getPack`, we can
statically determine that `Pack` is non-negative at this point.
ortho: use early return style pervasively in 'segCmp'
Because the leaf of each conditional was returning, we can write all this logic
without `else`. The result seems marginally cleaner and easier to read.
Allocation within this function chose between an on-stack buffer and a
heap-allocated buffer based on the length of the input string. With a modern
performant allocator this is often a de-optimization. This change switches to
unconditionally using a heap-allocated buffer, simplifying the code.
Allocation within this function chose between an on-stack buffer and a
heap-allocated buffer based on the length of the input string. With a modern
performant allocator this is often a de-optimization. This change switches to
unconditionally using a heap-allocated buffer, simplifying the code.
C:\GitLab-Runner\builds\graphviz\graphviz\cmd\tools\gxl2gv.c(694): warning
C6262: Function uses '20020' bytes of stack: exceeds /analyze:stacksize
'16384'. Consider moving some data to heap.
[C:\GitLab-Runner\builds\graphviz\graphviz\cmd\tools\gxl2gv.vcxproj]
So this function attempts to allocate ~20KB of stack data. Most of this is due
to the `buf` array. Using this much stack can cause crashes in constrained
environments. The buffer in question is used to read XML data in chunks, so we
can instead use the C standard library’s constant `BUFSIZ` that tells us the
optimal chunk size with which to perform I/O.
This change avoids the described problem as well as being a performance
optimization.
add 'gvmap' and 'gvmap.sh' to the CMake build system
Something strange I discovered while integrating this: the CI CentOS Autotools
jobs happily build and install `gvmap` and `cluster` despite not having libgts
installed. That is, the libgts dependency claimed in cmd/gvmap/Makefile.am
appears spurious. This all works out because nothing in that Makefile properly
indicates a requirement for libgts, so Make happily evaluates `$(GTS_LIBS)` to
the empty string.
And yet, when you attempt to remove this libgts usage you will find the CI
Ubuntu Autotools jobs fail. There is apparently a transitive dependency on
libgts when it is installed. So we leave everything as-is for now.
None of this is a concern in the CMake build system because CMake understands
transitive dependencies and applies these without having to be explicitly told.
But in future we should probably trace what the exact relationship of these
tools to libgts is.
gvmap: fix pointer-vs-int confusion in calling 'gv_recalloc'
This was a typo in 0e53497fae6e05a59c31b7f124ddd1166901759f. It seemingly went
unnoticed amid the torrent of warnings the Autotools build emits. I only picked
this up when enabling this code in the CMake build system that compiles with
-Werror in CI.
Magnus Jacobsson [Sun, 15 May 2022 09:19:26 +0000 (11:19 +0200)]
upgrade jinja2 to version 2.11.3
Fixes this error when using python 3.10:
Traceback (most recent call last):
File "/usr/bin/gcovr", line 33, in <module>
sys.exit(load_entry_point('gcovr==5.0', 'console_scripts', 'gcovr')())
File "/usr/lib/python3/dist-packages/gcovr/__main__.py", line 280, in main
error_occurred = print_reports(covdata, options, logger)
File "/usr/lib/python3/dist-packages/gcovr/__main__.py", line 432, in print_reports
if generator(covdata, output.abspath, options):
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 281, in print_html_report
css_data = CssRenderer.render(options)
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 121, in render
template = templates().get_template('style.css')
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 44, in __call__
return self.get(*args)
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 33, in load
result = fn(*args)
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 52, in templates
from jinja2 import Environment, PackageLoader
File "/root/.local/lib/python3.10/site-packages/jinja2/__init__.py", line 33, in <module>
from jinja2.environment import Environment, Template
File "/root/.local/lib/python3.10/site-packages/jinja2/environment.py", line 16, in <module>
from jinja2.defaults import BLOCK_START_STRING, \
File "/root/.local/lib/python3.10/site-packages/jinja2/defaults.py", line 32, in <module>
from jinja2.tests import TESTS as DEFAULT_TESTS
File "/root/.local/lib/python3.10/site-packages/jinja2/tests.py", line 13, in <module>
from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' (/usr/lib/python3.10/collections/__init__.py)
We cannot upgrade to jinja 3.x since gcovr would then give this error:
Traceback (most recent call last):
File "/usr/bin/gcovr", line 33, in <module>
sys.exit(load_entry_point('gcovr==5.0', 'console_scripts', 'gcovr')())
File "/usr/lib/python3/dist-packages/gcovr/__main__.py", line 280, in main
error_occurred = print_reports(covdata, options, logger)
File "/usr/lib/python3/dist-packages/gcovr/__main__.py", line 432, in print_reports
if generator(covdata, output.abspath, options):
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 401, in print_html_report
lines = formatter.highlighter_for_file(data['filename'])(source_file.read())
File "/usr/lib/python3/dist-packages/gcovr/writer/html.py", line 159, in highlighter_for_file
from jinja2 import Markup
ImportError: cannot import name 'Markup' from 'jinja2' (/root/.local/lib/python3.10/site-packages/jinja2/__init__.py)
xdot: replace inline agxbuf copy with canonical cgraph version
This de-duplicates some code, reducing ongoing maintenance. It also fixes some
int-as-size_t usage as well as some allocations that were unchecked for failure.
These functions are good candidates for inlining, which can be made possible
even without Link-Time Optimization by inlining them into this header. However
the main motivation for this change is to allow using these in code that does
not link against cgraph, lib/xdot, and thereby de-duplicate some code.
This required adding explicit casts to the alloc wrapper calls because this code
is seen by the C++ compiler when compiling parts of Graphviz. We can also drop
the API macros and C linkage, as these are not relevant for symbols that are not
exported.
This will be relevant in an upcoming commit that inlines these implementations
into the header, needing to call `agxbmore` which previously was only prototyped
below them.
This provides stronger type safety with no loss of performance. Note that this
also alters the implied type signature of `agxbuflen` to have a more appropriate
return type. This allows dropping one cast at a call site squashing another
warning.
gv2gml: remove 'outFile' parameter to 'emitSpline'
The only call to this function passes `outFile`, an already available global
that this parameter was shadowing. This removes numerous -Wshadow warnings.
The only calls to this function pass `outFile`, an already available global that
this parameter was shadowing. This removes numerous -Wshadow warnings.
gv2gml: remove 'outFile' parameter to 'emitNodeAttrs'
The only call to this function passes `outFile`, an already available global
that this parameter was shadowing. This removes numerous -Wshadow warnings.
gv2gml: remove 'outFile' parameter to 'emitEdgeAttrs'
The only call to this function passes `outFile`, an already available global
that this parameter was shadowing. This removes numerous -Wshadow warnings.
The only call to this function passes `outFile`, an already available global
that this parameter was shadowing. This removes numerous -Wshadow warnings.
The only call to this function passes `outFile`, an already available global
that this parameter was shadowing. This removes numerous -Wshadow warnings.
`gv2gml` would produce GML that `gml2gv` was unable to parse. The GML spec¹ is
imprecise about what is allowed, so lets be generous and assume integer values
are acceptable.
graphml2gv: undo micro-optimization in 'endElementHandler'
This code was deciding between using a static stack buffer and a dynamic heap
buffer depending on the length of the string it needed to deal with. This kind
of optimization is unnecessary on modern platforms with performant allocators.
The branching and structure duplication involved in this is often now a
_de-optimization_ instead of the intended optimization.
This commit undoes this trick and instead unconditionally uses heap allocation.
projects / graphviz / log