Re: [Devel] Use of qsort

[Antoine Leca]

Salut David,

And by the way (looks like I forgot to mention it),

Hi Tom,

David Turner wrote:
> 
> The easy thing is to provide our own implementation of quick sort
> (or heap sort, shell sort, whatever seems simpler and not too quadratic),
> since this completely avoids the problem. Actually, there already is
> so rather "reusable" quick sort algorithm in the smooth rasterizer
> (using a custom algorithm is critical for performance here)

OK, but I feel this is not as easy as it should...
Remember, the problem occurs in Freetype 1, in an extension...

Now, if you feel this is easy, and below one hour of work, please hack it!

 
> Other than that, I think that the only viable alternative is to use
> yet another configuration macro to declare/define callback functions.

So did I.

> Actually, I just modified the definition of FT_CALLBACK_DEF (which is
> used to tag C callback functions when compiling the library in C++
> mode, thanks to Werner), as follows in "include/freetype/config/ftconfig.h":

OK, I will take a look at that, and when I got it, I will cut and paste
it into Freetype 1.x.
A matter of several days, according to my heavy planning; since the "problem"
is here for more than a year, I doubt this is a real problem.

 
> I just hope that the special keyword doesn't need to be within the
> return type and the function name in the definition.

Guess what...
Yes, it needs to be inside, as always (I would struggle the guy at
Lattice, Microsoft or whatever that insisted for these additional
keywords far, near and cdecl to go between the type and the name, and
nowhere else. Even if I know why (it has to do with far/near being
able to decorate either the function, or the returned type if it is
a pointer)).


> Otherwise, we'll need to define FT_CALLBACK_DEF(), and replace all
> uses in the source code..

Yes, the ugly way.
Since I have to hack all this part to implement FT_EXPORT_DEF() in
Freetype 1.x anyway (it is still a non-function macro, and this does
not work for DLLs, as you know), this is something that can be done.
Food for work.


> > 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).
> >
> I believe that I didn't use any standard library function when writing
> the library. The "qsort" was introduced later, and I should have checked
> the issue at that time !!

Well, I did not notice the problem even if I did an extensive check, with
rebuilds using a variety of compilers, about six months ago. Looks like
the check was not as extensive as it should, and better I found it now!!


Antoine