[MPlayer-dev-eng] [PATCH] fix stack usage in libvo/font_load_ft.c

[Rich Felker]

On Wed, Jul 26, 2006 at 01:22:49AM +0300, Ivan Kalvachev wrote:
> 2006/7/25, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> >Hello,
> >On Sat, Jul 22, 2006 at 12:01:53AM -0400, Rich Felker wrote:
> >> On Fri, Jul 21, 2006 at 08:34:22PM +0000, Tobias Diedrich wrote:
> >> > read_font_desc_ft allocates ~1MB on the stack on amd64
> >> > (MAX_CHARSET_SIZE is 60000 and sizeof(FT_ULong) is 8).
> >>
> >> WTF is FT using an unsigned long type for? Someone should tell them
> >> they're being stupid and that they should use wchar_t, or just int.
> >
> >Well, but maybe it is us who are being stupid, because this gigantic
> >array seems to be used only in check_font around line 173, which raises
> >at least two questions:
> >Why are we using FT_ULong and not e.g. int32_t?
> >Why are we passing these arrays around (60000 is the maximum size, which
> >I guess might be a bit small for some stuff anyway?) instead of e.g. a
> >function that provides the mapping?
> >Actually for proper unicode support that whole stuff needs to be changed
> >not to use the current kind of mapping with a constant-size array.
> >64k characters isn't that much really.
> 
> FT_ULong is what freetype uses for characters. It is in their
> documentation (FT_Get_Char_Index).

Someone should tell them they're being idiots and need to fix this.
Making a type named "yourlib_ulong" is utter nonsense since it's
obviously supposed to duplicate the "unsigned long" type of the
compiler. The correct type would be something like FT_uint32 or
FT_glyphindex or whatnot. Stupid type definition only shows that they
don't know how to code....

> 64k is about the number of main unicode (remember when MS though 2
> bytes are enough for unicode?)

What if Mormons want to have subtitles in Deseret? :)))

Rich