On Sun, Jun 24, 2007 at 12:25:06PM -0400, John Belmonte wrote:
> Enrico Tassi wrote:
> > There is not API using long double, but there is some interesting
> > message in the header file (the configuration one).
> >
> > You probably know more than me about alignment in these archs...
> >
> > /*
> > @@ LUAI_USER_ALIGNMENT_T is a type that requires maximum alignment.
> > ** CHANGE it if your system requires alignments larger than double. (For
> > ** instance, if your system supports long doubles and they must be
> > ** aligned in 16-byte boundaries, then you should add long double in the
> > ** union.) Probably you do not need to change this.
> > */
> > #define LUAI_USER_ALIGNMENT_T union { double u; void *s; long l; }
>
> I don't think the macro should be changed because it will create a
> binary incompatibility on those archs.
>
> It seems like upstream should control use of long double in this struct
> with a define, and set it for the linux build target. Without this
> standardization there will be a binary compatibility confusion mess in
> the future.
What is not clear to me is:
1) Do plain lua (with no LUA_NUMBER redefinition) use long double?
For sure not in the interface, didn't check the internals but I guess
no.
2) Do these archs need long double (128 bit) to be "aligned"?
If they need alignement of 16 bytes, and lua uses long doubles, then
I'll ping the upstreams for such a macro to be active if the specific
arch and glibc version is met.
In any case, since there are no long double in the lua C interface,
there should be no ABI change and no package rename. If both the
previous points are met, the problem is that lua may crash due to a bus
error, and in this case we should work with the upstreams.
Am I wrong?
Cheers.
--
Enrico Tassi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
