fix changelog entry that was entered under an older release
When rebasing 8f60584180071ab9c0f212c3f31aac1d53ed4757, I mistakenly forgot to
adjust its changelog entry for the release that had happened in the intervening
time.
ortho: push trapezoids allocation into 'construct_trapezoids'
This makes it more obvious to readers and the compiler that the value of this
on-entry to `construct_trapezoids` is unimportant and the value does not need to
be retained between the two `construct_trapezoids` calls in `partition`.
The ortho library estimated the number of trapezoid structures it would need
upfront based on the number of segments it was operating on. This estimation was
wrong. Some inputs could exceed the estimation, at which point Graphviz would
abort with an error message.
This change makes trapezoid allocation dynamic, with the trapezoid collection
being expanded on-demand as new trapezoids are needed. The number of the
trapezoids is now only constrained by how much available memory there is.
ortho: stop passing decomposition boxes size around
With the horizontal and vertical decomposition boxes being managed dynamically,
their size is already stored in the `boxes_t` struct and we can use that
instead.
ortho: manage decomposition boxes as dynamic arrays
There is now no need to predict the number of horizontal and vertical
decomposition boxes upfront. The arrays for both are expanded on-demand.
This is a step towards resolving an issue where the upfront estimated trapezoid
count is exceeded, but this is likely an optimization for most workloads where
the estimation is not exceeded. Now fewer decomposition boxes will be allocated
because we generally do not need the full count that was estimated previously.
This is not great practice, putting functions like this into a header. But this
is a stepping stone to reusing this code in lib/ortho and it seems cleaner than
trying to manage yet another set of partially exported symbols.
The number of elements in this array is no longer calculated upfront; we simply
expand the array as needed. This removes one blocker to removing calculation of
the number of trapezoids upfront.
As noted in the comment in this commit, the first element (index 0) is reserved.
I do not know the motivation for this, but various places use index > 0 to
decide if they are dealing with a real node.
ortho init_query_structure: separate assignment statements
This looks like a pure readability change, but is actually preparation for an
upcoming commit. A future commit alters `newnode` to reallocate `qs->data`.
Without the current change, there is no sequence point between the index into
`qs->data` at the start of these lines and the reallocation (in future)
performed by the function call at the end of these lines. This is undefined
behavior with respect to the C standard.
This is quite a subtle problem. I initially did not spot it and was only alerted
by failures under CentOS 7, which encountered nodes with an invalid `nodetype`.
This problem was not reproducible on any other platform, even under ASan and
UBSan. What I believe was going on here is that the combination of the C
compiler and the Glibc on CentOS 7 is the only environment we have which
accidentally leveraged this undefined behavior, by sequencing these operations
as indexing into `qs->data` and _then_ performing the reallocation, resulting in
a write to invalid heap memory.
Similar to the prior changes to `trap_t`, this is a step towards allocating
these on-demand and thus removing predictions/estimations about the total
required qnodes.
ortho: track number of trapezoids along with its array
This is an alternative to passing around `ntraps` or relying on the `TRSIZE`
computation. It is a step towards fixing an issue where the allocated number of
trapezoids is exceeded.
The diff looks large but most of this change is mechanical, migrating `tr` uses
to be aware of the new structure.
This introduces some new warnings, but the intention is to remove these in
upcoming commits as we switch to on-demand allocation.
`qtree_level_optimizer` would be optionally allocated based on
`n >= ctrl->quadtree_size` but then would only be freed if `USE_QT` was set.
`USE_QT` is always false (it will be removed in an upcoming commit), so this
clean up never runs. This seems latent; I suspect the branch that allocates
`qtree_level_optimizer` is unreachable because this function appears to have
been copy-pasted from one of the other variants in this file with little regard
to how much of it is dead code. But it still seems wise to fix this issue.
sfdpgen check_int_array_size: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
sfdpgen check_real_array_size: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
remove unused 'PLATFORMSDKINCLUDE_ESCAPED' build system variable
This was using syntax incompatible with POSIX /bin/sh. But the last use of this
was removed in bd879b4583b32e4d13e4b36bea0c20f530fbca0c, so lets just remove it.
Revert "core plugin: stop emitting an empty 'alt' tag in cmap output"
This reverts commit a214b9dc2be6b4a9d27196e2c43f7bf2b0ff0002. It turns out the
W3C specification for this part of HTML requires the `alt` attribute if the
`href` attribute is set. We will need to figure out an alternative of what to
set this to for accessibility.
Gitlab: closes #2319, re-opens #265 Reported-by: Albert
This count is never intended to go negative. So using an unsigned type gives us
one more bit. Though reference counts of this object are not expected to reach
2³¹, so this is mostly just for clarity.
neatogen vpscAdjust: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen fdpAdjust: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen makeMatrix: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen getSizes: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen sortSites: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen makeInfo: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkNodelist: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen init_nodelistitem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen makeDerivedNode: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen circular_init_node_edge: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkItem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen position: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkBlock: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen find_pair_edges: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkItem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The Autotools build system was doing quite a bit of work to try and find a
`date` syntax that worked on the current platform and still failing (this logic
does not work on NetBSD). We can side step all of this by just doing date
manipulation in Python which we were calling anyway.
projects / graphviz / log