![](https://secure.gravatar.com/avatar/afe01bb432ddbd86d99b8f84ade5917a.jpg?s=120&d=mm&r=g)
Hi, I found some odd behaviour, arguably a bug or two, when I added bounds checking to _param_base, in struct texfont. As I have fixed this in my own code, this is just FYI. At about line 750 in mlist.w: DEFINE_DMATH_PARAMETERS(math_param_radical_vgap, size_id, (default_rule_thickness(size_id) + (abs(math_x_height(size_id)) / 4)), lvl); default_rule_thickness turns out to be math parameter 8. But at least font 0 (nullfont) has only 7 parameters (according to _font_params). Parameters are Pascal-style (one-based) so there has to be one more element that parameters. Still, parameter 8 is outside the array bounds. But! When reallocating the _param_base array, the set_font_params() allocates not only one, but two, extra elements, so accessing parameter 8 works. The extra extra element is not initialized by set_font_params(), but either it is never actually used, or dynamic memory is zero-filled by default. These bugs are present int 0.95.0. They may or may not be present in later versions. Clarification: by bugs I mean a) accessing outside the logical bounds, and b) not initializing all elements. One quick way to fix it would be to check the parameter number in font_param(), and return 0 if out of bounds. Regards /Lars ------------------------------------------------------------------- Lars Hamrén WWW...: www.sdu.se Vadmöllan 211 Mobile: +46(705)189090 S-225 94 Lund Sweden
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Fri, Nov 11, 2016 at 8:49 PM, Lars Hamren
Hi,
I found some odd behaviour, arguably a bug or two, when I added bounds checking to _param_base, in struct texfont.
As I have fixed this in my own code, this is just FYI.
At about line 750 in mlist.w:
DEFINE_DMATH_PARAMETERS(math_param_radical_vgap, size_id, (default_rule_thickness(size_id) + (abs(math_x_height(size_id)) / 4)), lvl);
default_rule_thickness turns out to be math parameter 8.
But at least font 0 (nullfont) has only 7 parameters (according to _font_params). Parameters are Pascal-style (one-based) so there has to be one more element that parameters. Still, parameter 8 is outside the array bounds.
But! When reallocating the _param_base array, the set_font_params() allocates not only one, but two, extra elements, so accessing parameter 8 works.
The extra extra element is not initialized by set_font_params(), but either it is never actually used, or dynamic memory is zero-filled by default.
These bugs are present int 0.95.0. They may or may not be present in later versions.
Clarification: by bugs I mean a) accessing outside the logical bounds, and b) not initializing all elements.
One quick way to fix it would be to check the parameter number in font_param(), and return 0 if out of bounds.
Regards /Lars
Thank you very much for your report and my apologies for delay of the answer. We are currently quite busy but there should be a debugging session at the end of current month, and we will see this issue as the others as well. -- luigi
![](https://secure.gravatar.com/avatar/afe01bb432ddbd86d99b8f84ade5917a.jpg?s=120&d=mm&r=g)
Hi, Luigi
Thank you very much for your report and my apologies for delay of the answer.
It's good to know that they are appreciated. Zooming out, I'm not sure I think that the variable arrays of parameters are a good idea. The original idea was to be both flexible and memory-efficient, but by modern standards the amount of memory is miniscule, and the arrays don't do the readability of the code any good. I will probably drop them in favuor of regular struct member variables. I may be wrong, so if you or anyone else have convincing arguments in favour of the arrays, I look forward to hearing them.
We are currently quite busy but there should be a debugging session at the end of current month, and we will see this issue as the others as well.
Good luck! I have already applied local fixes, so don't feel any pressure on my behalf. /Lars
participants (2)
-
Lars Hamren
-
luigi scarso