Re: [AD] Problems with gcc 3.1

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 23 Oct 2001, salvador <salvador@xxxxxxxxxx> wrote:
> Let me see if I understand the idea: by default the headers define fsqrt as
> an alias to fixsqrt. If it generates problems for the user then defining
> ALLEGRO_NO_FIX_ALIASES the alias goes away. Right?

That was my original intent.  But as you pointed out, I wasn't
thinking clearly.

> My doubt is about who will do it: the user or some conditionals in the
> header?
> If gcc 3.1 still defining fsqrt when is labeled as stable (and all indicates
> that's the case) all the people using gcc will need it.
> I know breaking old programs isn't nice. So I think the header itself should
> avoid defining fsqrt if the target will collide. Is that what you say?

(a) On one hand, I think we should NOT provide the aliasing, unless
the user explicitly asks for it.  This would be done by #define'ing
ALLEGRO_FIX_ALIASES before #include'ing allegro.h.  If you want to
compile an older program, you can simply use gcc -D (or whatever for
other compilers).

(b) On the other hand, the conflicts are kind of rare.  So we should
rename the f* functions to fix*, but provide aliases by default.  If
the user really needs to use the libc/m fsqrt (etc) instead of
Allegro's fsqrt (etc), he can switch off the aliases.  The aliases
would be static inline functions, so even if you use Allegro's fsqrt
in one module, you can still use the system's fsqrt in another.  If
done right, there shouldn't be any warnings or anything.

I'm leaning towards (b) at present.  Five minutes ago I was leaning
towards (a).  But (b) is better :-)



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/