When swallowing a single line comment (C-style "//..." or shell-style "#..."),
lib/gvpr would push the trailing newline into its output buffer as well as
yielding it. The effect of this was that the second stage parsing done by
lib/expr would see two newlines, throwing off its recorded line number by one
for each single line comment. Fixes #1594.
gv_doc_template.tcl: Pass "-gmt True" to support reproducible dates.
While the code already uses SOURCE_DATE_EPOCH, it also needs to ensure
that the times are emitted in UTC/GMT, otherwise building on machines
configured with different timezones may result in different embedded
timestamps.
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
Bison only includes the legacy malloc.h header when using alloca() on Windows,
when YYSTACK_USE_ALLOCA is defined. The Graphviz build does not define this for
any generated parsers. Related to #1242.
remove use of deprecated pango_cairo_font_map_create_context
This API was deprecated in version 1.22 of Pango [0], released in 2008 [1]. The
one place that supported both the new and old API was still always calling the
old API as the build system does no HAVE_PANGO_FONT_MAP_CREATE_CONTEXT
detection.
Magnus Jacobsson [Tue, 30 Jun 2020 08:49:01 +0000 (10:49 +0200)]
Update DEVELOPERS.md after 2.44.1 release
* Change to use merge request
* Remove obsolete remarks about fork or clone differences
* Update all example commits
* Change to use 2.44.1 in all examples
* Provide more detail a little here and there
* Remove tagging with stable_relase_<version>
* Remove update of web page which is now version agnostic
* Remove TODO section since there's no longer anything to do
remove unnecessary intdeallocator for IntegerVector
The underlying vector implementation anticipates that the destructor may be
null, so there is no need to provide an empty deallocator. We could simply
delete the IntegerVector implementation as nothing is currently using it, but it
looks like it may be of use in dealing with #1554.
This function checked if its second allocation to the vector's backing array
failed, but did not check if the original data structure allocation failed. It
is somewhat unlikely callers are currently equipped to handle this failure
anyway, but we may as well be consistent here.
Magnus Jacobsson [Wed, 24 Jun 2020 11:07:14 +0000 (13:07 +0200)]
Change to use patch version in the Windows installer
This changes the version in the Graphviz installer .exe produced by
CMake to use the patch version number instead of the build
date. Still, if the patch version is "$GRAPHVIZ_VERSION_DATE", the
patch version will be set to the build date. This conforms with how
the Linux packages are created.
This change affects the filename of the installer, the version
presented to the user in the installer GUI, the installation path and
the version presented by the running software.
Magnus Jacobsson [Thu, 18 Jun 2020 11:08:04 +0000 (13:08 +0200)]
Make CMake get Graphviz version from autogen.sh by parsing it
This will make autotools and CMake builds have a single source of
truth for the Graphviz version.
First, the major, minor and patch versions are retrieved. If the patch
version is "$GRAPHVIZ_VERSION_DATE", the patch version is set to the
committer date of the latest commit. This effectively repeals part of
the intention of 266ff5ee80b2d91231907e90ec650154f5225aa5: "Don't
encode build date stamp in it to be able to create reproducable
builds".
Address Sanitizer detected a few instances of the following:
Direct leak of 168 byte(s) in 7 object(s) allocated from:
#0 0x7f4bc2724330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f4bc24b1ea3 in vec_new /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:918
#2 0x7f4bc24b291a in find_all_cycles /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1073
#3 0x7f4bc24b2b64 in get_cycle_centroid /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1121
#4 0x7f4bc24b3c5c in makeStraightEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1233
#5 0x7f4bc24b35f8 in makeStraightEdge /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1203
#6 0x7f4bbdf28b52 in _spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:659
#7 0x7f4bbdf29240 in splineEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:736
#8 0x7f4bbdf29310 in spline_edges1 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:749
#9 0x7f4bbdf293be in spline_edges0 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:779
#10 0x7f4bbdf29bcb in spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:817
#11 0x7f4bbdf14ea6 in neato_layout /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatoinit.c:1489
#12 0x7f4bc242b6fc in gvLayoutJobs /tmp/tmp.m68Z0dFAYs/graphviz/lib/gvc/gvlayout.c:85
#13 0x559fcd474960 in main /tmp/tmp.m68Z0dFAYs/graphviz/cmd/dot/dot.c:132
#14 0x7f4bc21d709a in __libc_start_main ../csu/libc-start.c:308
find_all_cycles() was calling vec_delete() on the temporary vector it allocated,
but it did not take into account that the nested vectors were not freed by
vec_delete(). This change moves the open coded clean up logic from
get_cycle_centroid() into vec_delete() to fix this and make it less likely that
this is missed in future.
This was initially encountered while investigating #1554.