Hi Alexei, Alexei Podtelezhnikov schrieb: > Do you understand why they are so averse to large stack allocations?
I am a long time lurker on this list just for this reason ;-). AROS (an AmigaOS3 API compatible OS) has inherited the not automatically growing stack of AmigaOS. As AROS mainly uses freetype for rendering of fonts (thanks for that!) the problem with large stack allocations exist also there. The problem is that the freetype library must live within the stack size of the calling executable and the application might not expect such large allocations from a library. I decided not to send in any patches as AROS is not so widely used and my patches are sufficient for AROS. I assumed this problem is not an issue for anybody else. My patches use the native AROS memory allocation functions so can't be integrated without rewriting, but they are trivial (more or less just malloc/free). I patched the following functions in freetype-2.10.4 which caused problems on AROS: src/autofit/afcjk.c: In af_cjk_metrics_init_widths() hints[1] and dummy are quite big. src/autofit/aflatin.c In af_latin_metrics_init_widths() hints[1] and dummy are quite big. src/autofit/aflatin2.c In af_latin2_metrics_init_widths() dummy[1] is quite big. src/autofit/afmodule.c In af_autofitter_load_glyph() hints[1] and dummy are quite big. I patched the AROS compiler code to monitor the stack usage of each freetype function while running executeables and the rest of the freetype code seems not to use much stack but I might not have covered every code path while testing of course. Regards o1i -- | Oliver Brunner | a...@oliver-brunner.de | "o1i" |