Follow-up Comment #6, bug #68812 (group groff): [comment #2 comment #2:] > Deri raised this class of issue in comment 15 to bug #68687.
Well, looking at the function printer::load_font(), that function does contain
a few obvious potential and/or theoretical problems - but the problem is *not*
that using the data type "int" for array indices is wrong in any way.
Instead, most, but not all, of the potential problems in that function are
related to a lack of boundary and overflow checking, for example:
* The sequence "assert(n >= 0); if (n < 0) ..." is nonsensical. Instead, we
should make sure that assert(3) is always honoured and never ignored. Blindly
returning when a violation of an invariant is detected is extremely dangerous
and foolish. When code already knows that its internal state is corrupted, it
must never be allowed to continue. So instead of "return", the code needs to
call abort(3) - but only if we can guarantee that no program using the library
ever installs a SIGABRT handler. Otherwise, exit(3) must replace the
"return". If calling exit(3) is not acceptable in that library - in many
libraries, it isn't, but then calling assert(3) is not acceptable either -
then the function printer::load_font() must be redesigned to report failure,
for example by returning 0 for success or -1 for failure, like many libc
functions do.
* There are at least two places where something is added to the input value n
without checking for overflow.
* The operator "new" is called on the font type without sanity checking for
unreasonably large values of the upper bound.
* The old nfonts value is doubled without checking for overflow.
* I'm not claiming completeness of my audit of the function.
If the function is used reasonably by the rest of the code, these potential
bugs are unlikely to matter. It may or may not make sense to fix some or all
of them, depending on the bigger picture. But that requires careful analysis
of the actual bugs, not some blanket and bogus conclusion like "don't use
'int' for array indices". That careful analysis of what the bugs actually are
*cannot* be automated, and potential fixes cannot be automated either.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68812>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
