Enrico Tassi wrote: > 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.
Lua does not use long double. I think LUAI_USER_ALIGNMENT_T affects memory allocated for userdata (i.e. alignment of pointer returned by lua_newuserdata). If userdata is going to be a struct which includes a long double, updating the macro may be significant. We know this bug is a false positive and can be closed. The question raised is what happens when some Linux distributions start "fixing" that macro-- does it affect binary compatibility of the Lua core library or compiled Lua code? Hopefully not, but we'd have to check with the code or Lua authors to confirm. Regarding your #2, a complex test of architecture and glibc version is not necessary. It's enough to always put long double in the struct if the compiler supports the type. Since gcc does, and the Lua "linux" target uses gcc, I propose that it be enabled for that target. But I want it to happen upstream so there is consistency between distros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
