[bug #68585] [eqn, pic, tbl] code not "ASAN_OPTIONS=alloc_dealloc_mismatch=1" clean

--8323329-424238335-1785710154=:3481868
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

Update of bug #68585 (group groff):=0A=0A             Assigned to:         =
           None =3D> gbranden=0A         Planned Release:                  =
  None =3D> 1.25.0=0A                 Summary: [pic,tbl] code not=0A"ASAN_O=
PTIONS=3Dalloc_dealloc_mismatch=3D1" clean =3D> [eqn,pic,tbl] code not=0A"A=
SAN_OPTIONS=3Dalloc_dealloc_mismatch=3D1" clean=0A=0A    __________________=
_____________________________________=0A=0AFollow-up Comment #4:=0A=0AHi Br=
uno,=0A=0A[comment #3 comment #3:]=0A> Find attached five patches, that fix=
 all the ASAN issues in a "make -k check"=0A> run.=0A=0AOutstanding!=0A =0A=
> Some ASAN findings became visible only after other ASAN findings were fix=
ed,=0A> that's why it needs five patches and not only two.=0A=0AYup, I'm no=
t surprised at all.  Fear of revision scope creep and risk of=0Aimposing de=
lay on the release schedule--we've already missed the "early July"=0Achrono=
logical objective, which is much more my fault than anyone else's--is=0Awhy=
 I shied away from making resolution of this/these issue(s) a release goal=
=0Afor 1.25.0.=0A=0ANot that _groff_, officially, _has_ "release goals".=0A=
=0Ahttps://lists.gnu.org/archive/html/groff/2026-06/msg00017.html=0A=0ABut =
your patches show that the impact radius of resolving this mildly=0Aworriso=
me issue is tightly constrained, utterly unlike my ramifying yarn-pull=0Aof=
 comment #1.=0A=0AThank you!=0A =0A> All that was needed is to call free(x)=
 instead of delete[] x in a few places.=0A> And updating comments, to avoid=
 future mistakes of the same kind. Note that=0A> for a similar case, there =
was already a comment=0A=0A> // `malloc()`ed by `string::extract()`=0A=0A=
=0A> in src/preproc/tbl/table.cpp.=0A=0AYes.  You found a bread crumb I had=
 intended to follow up on in the indefinite=0Afuture.  :)=0A=0AThere are us=
ually several potential modernizations or technical debt paydowns=0AI can s=
ee before me in any given screenful of _groff_ code.  It's challenging=0Ato=
 stay on one such issue long enough to eradicate it.  What more often=0Ahap=
pens is that I whack away at a breadth-based refactoring (vs. a depth-based=
=0Aone, where I heavily revise a single function) a few greps at a time ove=
r=0Amonths or years, interleaved with the other issues I work on.  Eventual=
ly, it=0Agets done.  Savannah tickets in Item Group "Refactoring" and tagge=
d with=0A"[long-term]" in the Summary are examples of these.=0A=0A>> trying=
 to resolve the tbl issue pulled on a long thread of=0A>> `const`-incorrect=
ness and an insufficiently well documented internal API for=0A>> libgroff's=
 "string" class.=0A> =0A>> One will observe that diff changed the return ty=
pe of `string::extract()`=0A>> away from the "reform" contemplated above.  =
That's because I worked=0A>> backwards from how tbl was using it.=0A> =0A> =
The changes that you are considering here are not needed for resolving the=
=0A> ASAN failures. No 'const' / non-'const' change and no function signatu=
re=0A> change is needed for this ticket.=0A=0AI concur.  Moving some intern=
als "back" to libc memory management functions is=0Anot a direction I wante=
d to go since I desired to move the code base purely to=0Athe C++ language =
allocator instead.=0A=0ABut allocator UI consistency, and ASAN cleanliness,=
 is a much more significant=0Avirtue than occasional, but symmetric, libc a=
llocator usage is a vice.=0A=0AMoreover, your changes don't make the eventu=
al "forward migration" of the=0Asites of allocator usage significantly more=
 difficult.  Any such revision=0Ashould involve a coupled check of both the=
 allocation and deallocation sites=0Aanyway, to ensure that the developer c=
omprehends the change and sniffs for=0Acode smells.=0A=0AI'll apply these c=
hanges to our master branch and expect them to ship in=0A_groff_ 1.25.0 fin=
al.=0A=0AThank you again!=0A=0A=0A    _____________________________________=
__________________=0A=0AReply to this item at:=0A=0A  <https://savannah.gnu=
.org/bugs/?68585>=0A=0A_______________________________________________=0AMe=
ssage sent via Savannah=0Ahttps://savannah.gnu.org/=0A
--8323329-424238335-1785710154=:3481868
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCam/GSgAKCRCqLAuaBUf3
TvdyAPwKF5nix3upydSX8CK2lJuWZOgde5GfjTlj+MVwAvP6tgD9H4jKgYtkSJUV
jiODo97sXL33bgByulQYDOcCVgARlA0=
=tK3Y
-----END PGP SIGNATURE-----

--8323329-424238335-1785710154=:3481868--