[Devel] Use of qsort

[Antoine Leca]

Hello guys,


It was a while I did not compile Freetype 1.x on BC++ 4.5, and
I found a quirk.

Recently (in term of Freetype 1.x development, in fact it was 15 months ago,
in April 2000), Just did introduce a fix in lib/extend/ftxkern.c, against
brocken fonts. To fix it, he did use qsort. As such, of course, he introduces
a new (static) function (here, compare_kern_pairs) that were passed as
4th argument to qsort.

However, this does not scale well with this damned DOS/Windows compilers :-(.
The problem arise because the standard parameter passing convention is
conventionnaly a broad-band one, namely _cdecl (parameters are on the stack,
unstacked by the caller, etc.) Of course, the standard C library is linked
against this convention, which means that the callbacks used (for example, by
qsort) are expected to use this convention, and no others.
In order to improve performance, various other conventions have been set up,
and we even select one of them (namely, __fastcall, which do use the available
registers for the first parameters), because the gain in performance is quite
important.

You should now see the problem: since we did not indicate anything special,
the compiler chose __fastcall for the static function that Just added. And
as qsort expects _cdecl, there are very few chances things work as expected...
I believe smart compilers could be programmed to handle the situation, but
there are (a lot of) unsmart compilers lying around, and obviously BC++ 4.5
is one of them. Fortunately, the compiler flags the mismatching convention as
an error, and did not allow me to continue too far.


OK, now you've understand the point (?), what do we do?
- either we modify every DOS/Windows Makefile and like to discard the __fastcall
  optimization (it looks like this is what VC++ 6 do by default)
  Doable, but this raises some potential pitfalls (if some did build its 
Makefile
  alone; or we destroy backward compatibility; pure performance is badly 
affected;
  etc.)
- or we introduce another config parameter, similar to FT_EXPORT, FT_LOCALDEF
  and the like, to tag those functions that are expected to be used as 
callbacks;
  by default the config parameters will do nothing, but it may be overridden
  if needed for the compilers that may need it. I favor this later.

Also, a thing worth checking is whether any other part of our libraries, being
1.x or 2.x, use any callback back to a standard library (qsort is just an 
example,
although it is probably the one which is the most probable).


Antoine