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
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
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